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.
