>> Here's how it *should* be made: the most superest, most badassed >> object should take care of its children. New instances should >> automatically call up the super chain (and not leave it up to the >> subclasses), so that the parent classes can take care of the chil'en. >> When something goes wrong the parent class has to look in and see >> what's wrong. > > So what you're saying is that the first class defined does everything, > and subclasses _restrict_ what can be done? I disagree strongly:
That's right. Just as the *machine* restricts what can be done. It's an upturning of the purity model and going back to practicality. > 1) That breaks the Liskov Substitution Principle. A subclass of list > ought to fulfill the contracts of a basic list. We don't need LSP. I write about this on the WIkiWikiWeb where there were many arguments documented and many hairs frazzled. LSP was derived from AlanKay's abstract idea of "Everything is an object". But no -- there is a *physics* for information, and it ends at the machine types. > 2) It implies that someone can invent an all-encompassing superclass > before any subclassing is done. No, we start with basic types and work upwards. The "all-encompassing" superclass it an all-encompassing data object: in mathematics, it's called a SET -- and mathematics has already done the work to prove that it's the most generic and all-encompassing, a field of SET THEORY. > This kinda violates the laws of > information. Programmers, being creative entities, will be adding to > the pool of knowledge. Trying to shoehorn everything into one object > won't work. No, we don't need programmers adding to the "pool of knowledge" -- the internet does that. We need programmers making data objects that can present data in new and more interesting ways -- starting from basic principles. -- MarkJ Tacoma, Washington -- http://mail.python.org/mailman/listinfo/python-list
