On Sun, Dec 8, 2013 at 2:33 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Sat, 07 Dec 2013 20:21:06 -0800, Mark Janssen wrote: > >>>>> Is it just me, or is this basically useless? >>>>> >>>>> class object >>>>> | The most *base* type >>>> >> [[Terry Reedy:]] >>> How about something like. >>> The default top *superclass* for all Python classes. >> >> How 'bout you foo<l>s just admit that you didn't realize you've been >> confused this whole time? (It *is* possible isn't it?) >> >> Mr. Ewing says "base" has to be interpreted as an *adjective* because >> otherwise it would mean the BOTTOM (like the BASE of the pyramid), while >> Terry responds that it is the TOP (*super*class). Earlier, Steven >> D'Aprano wanted to argue that this distinction was irrelevant, > > What are you talking about? Until this very post, I haven't made any > comments in this thread.
It was a few months ago. You do know what I'm talking about because you just expounded with the exact same argument below. It's like a broken record. (Now if *I* sound like a broken record, it's because no seems to see the obvious, but carry on.) >> but obviously it can't very well be both at once now cannit? > > Family trees and other hierarchies, including class inheritance diagrams, > have a *relative* direction not an absolute direction. We can all agree > that Fred and Wilma are the parents of Pebbles, but it doesn't really > matter whether we draw the family tree like this: > > > Fred Wilma (diagrams best viewed in a fixed-width font > | | like Courier, Monaco or Lucinda Typewriter) > +----+----+ > | > Pebbles > > > (inheritance goes *down* the page from ancestors to descendants) > > or like this: > > Pebbles > | > +----+----+ > | | > Fred Wilma > > > (inheritance goes *up* the page from ancestors to descendants). > > What matters is the relationships between the entities, not the specific > direction they are drawn in relative to some imaginary absolute space. > [yadda, yagni, yadda] But, there IS A DIFFERENCE. Let me explain the concept of a object model (or "type model" if you prefer). In a family inheritance tree, there is this difference -- called the "calendar" -- which imposes an ordering which can't be countermanded by flipping your silly chart around. You made a bullshit example to simply argue a point and *fooled yourself* into ignoring this. Yes? Likewise, WITH A COMPUTER, there is a definite order which can't be countermanded by simply having this artifice called "Object". If you FEE(L)s hadn't noticed (no longer using the insult "foo"s out of respect for the sensativities of the brogrammers), this artifice has just been *called on the floor* with this little innocent question that fired up this discussion again (don't hate the messenger). Again: people entering the community are pointing out a problem -- that Object is both trying to be the BASE and the SUPERclass of all objects. CS554: A type/object *model* has to define the relationship of these nice abstractions so that they can be mapped to the *actual concreteness* of the machine. And there, bro, there is an ordering. You're not going to magically flip the hierarchy so that your bitless Object becomes a machine word that is the base of all your types. You've been fooled by the magic of the Turing Machine. The modern computer mollifies you with the illusion of "total abstraction" where there are no bits or 1s and 0s involved, but yea, it did not turn out that way. (Note bene: as a comparison, C++ is very UNAMBIGUOUS about this fact -- all objects inherit from concrete machine types, which is why it remains important, *despite* being one of the worst to do OOP in. Its *type model* is probably the most clear of any object-oriented language). > Likewise it doesn't matter whether we draw class hierarchies from the top > down or the bottom up or even sidewise: Have you caught it by now, friends: IT MATTERS TO THE COMPUTER. With some apologies for Ned for attempting to be neutral. Apparently you guys are philosophers more than Computer Engineers. MarkJ Tacoma, Washington -- https://mail.python.org/mailman/listinfo/python-list