I consider that subclassing should be used for implementation reuse and not for subtyping. That is the GoF position and it makes a lot of sense to me. In fact, I think we Smalltalkers suffer from McLuhan's "people become their tools" syndrome in that, because the browser makes it easy to view inheritance trees, we confuse inheritance with subtyping, creating unnecessary coupling. This also adds to the "Smalltalk has no APIs" problem; when only subclasses are considered subtypes, one never has to define what is and is not the public API; protocols could help here, but have never really been fleshed out for this purpose and are a mess right now due to overloading with extension method duties.
+ 10
Definitely +1 to that. One of the things I really like about ENVY (as in VA Smalltalk) is the fact that applications/packages have formally modelled prerequisites and the in-image representation of a class also models the contribution of each extending application. (As opposed to "by convention") I worked with Envy too and to me this is close to the package we have. And soon we will have package level dependencies.
I'm not claiming ENVY is the be all to end all. It has room for improvement. But it does formally model this particular aspect quite well.
-- View this message in context: http://forum.world.st/Stack-tp4834494p4834964.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.