Steve Dekorte wrote:
> 
> I agree that a major problem in Smalltalk is that it's big and the
> dependences are not clear. There's no easy way of pulling out the
> stuff you don't need/want or starting from a next to clean slate. IMO,
> This is because classes are globals and globals are evil.

I disagree on two accounts.

1) Separation is difficult because a Smalltalk program has the ability
to generate calls that aren't in the source code. I.e. too much
(otherwise very useful) reflexive capabilities.
I say that because I know that all Eiffel compilers have global classes
and still the SmallEiffel compiler does a rather rigorous job of
throwing out every routine that isn't accessible. (A minimum Eiffel
program directly and indirectly uses a few dozen classes, each with one,
two dozen features, yet the SmallEiffel compiler strips this down to a
footprint of 4k.)
2) Immutable globals aren't bad. All integer literals are globals, as
are true, false, and nil. What's bad is mutable globals - and now we get
back to point #1: as soon as classes can be tampered with, all bets are
off wrt. what a system might need or not.

> Of course there are pure object languages where you can isolate
> namespaces within the system...

Namespaces would be an option. I'd like to see some way of tracking
classes that migrate from one namespace to another, like if there is a
class in namespace 'IndependentDevelopers/Steve', and it later makes it
into the core of the system, then clients that access the class under
the original name will be silently rerouted to the new kernel class.

Another problem would be setting up a good namespace structure. I guess
there are at least as many proposals as developers here. And IMHO a
namespace with a bad structure is worse than having no namespace at all.

Just my 2c.
Regards,
Joachim
-- 
Please don't send unsolicited ads.