Smalltalk and Python

Tim May tcmay at got.net
Fri Dec 15 23:05:31 CET 2000


In article <slrn93l2lc.5l.cerutti at fiad06.norwich.edu>, 
cerutti at together.net wrote:

> Alex Martelli posted:
> >[good discussion about squares and rectangels snipped]
> >
> >But that's implementation, and a well known
> >problem with inheriting-from-concrete in that
> >realm.  What I'm saying is that the problems with
> >inheritance-from-instantiable (fully concrete)
> >classes start much earlier than at implementation
> >time -- start with conceptual, ontological issues
> >regarding OOA and related classification tasks.
> 
> This problem arises from the way that our minds work. We like to
> classify things, and the classifications are incredibly
> complicated. Object Orientation doesn't model our minds very well
> due to the problems you discussed. We end up needing imaginary
> classes containinag, as practically as we can deduce, the
> commonalities in groups of objects we're modelling--for the sake
> of inheritance. In reality an ostrich and a blue-jay and a
> pengiun are all birds, but the relationships between them don't
> *really* go back to a primordial ideal BIRD. They're family
> relationships, which I don't know how to model.
> 
> Perhaps a new paradigm of "family oriented" programming will crop
> up some day?

Good point, but this is why many like "mix-ins" more than MI. 

The ostrich has certain bird-like features (bird chromosomes, feathers, 
egg-laying, etc.), but also has certain features of "ground-running 
only" things. That is, an ostrich runs on the ground like mammals or 
reptiles. 

But instead of saying that the ostrich class inherits from both the bird 
class and some other ground-running class, one would "mix-in" only the 
"ground-running-thing" items/behaviors/methods of interest. 

(And as we have seen some good arguments here in recent days, neither SI 
nor MI is necessary. Buying (or composing), as Meyer coined the term, 
are equally well-suited. In the ostrich case, the "ostrichness" of an 
ostrich may not be captured by any number of MI or mix-ins. Almost as 
efficient, perhaps, to just start from scratch.)


--Tim May

-- 
Timothy C. May         tcmay at got.net        Corralitos, California
Political: Co-founder Cypherpunks/crypto anarchy/Cyphernomicon
Technical: physics/soft errors/Smalltalk/Squeak/agents/games/Go
Personal: 1951/UCSB/Intel '74-'86/retired/investor/motorcycles/guns





More information about the Python-list mailing list