To submit a letter, e-mail us email@example.com
I liked the article “Schizoid Classes,” (September 2004) but disagree with the statement, “In C++ and Java, the construct called a class is neither a module nor a type…” [my emphasis]. Here’s my favorite definition of class: “A class is a module AND a blueprint for modules. The modules constructed according to such a blueprint are usually called ‘objects of the class’.”
Conceptually, each object of a class contains a copy of every object attribute and every object method (and every other object member) of the class. The methods ob1.m (method m in the module/object ob1) and ob2.m are obviously two distinct methods, since they may yield different results for the same arguments and may have different side effects (e.g., on private attributes in ob1 or ob2, respectively).
Several implementations of Java and C++ supposedly use certain clever tricks to avoid many copies of the same method, but that does not change the simple idea that an object fundamentally is just a module containing attributes and methods.
Ulrich Grude, Berlin, Germany
RODNEY BATES RESPONDS: It appears that Ulrich Grude’s disagreements with me are mostly terminological, rather than conceptual.
Don’t Forget to Vote!
I enjoy reading Stan Kelly-Bootle’s material—especially “Vote Early, Vote Often” (September 2004).
Yes, you do already have my vote, if you want it. Reading your columns always provides my brain with a good workout. That’s more than I can say for any other candidate.
Anneliese Gimpel, Collegeville, Pennsylvania
STAN KELLY-BOOTLE RESPONDS: After checking for any dangling if/else’s and chaddim, we have duly verified your virtual vote.
Expect favorable changes in your tax rates, medication costs, and life expectancy in the not-too-distant future.
I may have failed to mention the mandatory SKB Supporters’ Fund, but I know your generosity will match your faith in my unbounded benevolence.
Something about Simulators
The sidebar in Bob Supnik’s “Simulators: Virtual Machines of the Past (and Future)” (July/August 2004) contains an inaccuracy in the statement: “The x86’s ‘little endian’ byte order derives from the PDP-11.” The x86 byte order is a result of backward compatibility to the Intel 8008, which was based on a design for an eight-bit processor architected by Datapoint, whose initial spec was for a big-endian machine!
When Intel started to lay out the processor to Datapoint specs, it found that transistors could be saved by using LSB first byte order, so Datapoint architects Victor Poor and Harry Pyle agreed to the change (one of only a few to their architectural design).
The original Intel 8008 ended up being implemented in 6,000 to 7,000 transistors—amazingly small compared with modern machines.
Henri Socha, Salinas, California
BOB SUPNIK RESPONDS: I would agree, having read the 8080 specs, that it does implement little-endian byte order, and that the 8086 undoubtedly derives from that.
Interestingly enough, the PDP-11 was announced at just about the same time (mid-1969) as Intel was reaching its transistor-count-driven conclusions for the 8008. The PDP-11 went little endian for different reasons: If you address location A, it gives useful data whether you are fetching 8b or 16b out of 32b (i.e., the low 8b or 16b of a 32b item). The bit order was intended to represent powers of 2.
Note that bit order and byte order were not coupled: the HP2100 used right-to-left bit order but left-to-right byte order.
The Bigots of the World
In “A Bigot by Any Other Name” (May 2004), Josh Coates discusses bigotry in the software development world. Well, in the open source world the usual term for this crowd is the “Slashdot peanut gallery.”
Ian Phillips, London, United Kingdom
We edit letters for content, style, and length.
Originally published in Queue vol. 2, no. 8—
see this item in the ACM Digital Library
EDWARD GROSSMAN is an abstraction layer.For additional information see the ACM Digital Library Author Page for: Edward Grossman