Hi!

> Todd Blanchard wrote:
>> I'm in favor of that - but honestly, there hasn't been a lot worth
>> stealing from the mainstream.
>
> Really? Namespaces? Modules? Interfaces? Every even remotely mainstream
> language I am aware about has at least two out of these three - you
> don't find those worthwhile?

Ah. Yummy. That word again. :) Totally disregarding the point Andreas is
trying to make (which I agree on btw), let me ramble off:

- Namespaces. In my opinion this one is a hard one. Sure, we do need it
from time to time in different scenarios, but it sure is hard IMHO to
introduce a solution that doesn't "hurt" the feeling of Smalltalk.
Including my own proposal which tries damn hard though.

- Modules. This one would be neat to have in some fashion. I consider the
word to mean "independently deployable unit" btw. Today MC is more or less
grabbing this space (in a fashion) but with an SCM focus instead of
deployment focus.

Sidenote: I have toyed with an idea that a Module would simply consist of
a serialized object chunk (normally a Set of classes a la an mcz snapshot)
that has required inputs in the form of a list of globals and offered
outputs in the form of a list of globals. Loading a module would be
possible even if the required input globals weren't complete - it should
then create a temporary binding that another Modules later can "fill in".
This would make load order independent. Sure, it would not deal with
"extension methods" a la MC - but perhaps it shouldn't?

- Interfaces. Yes, might be neat to have. Traits touch on this a bit and
we also have SmallInterfaces (which I never have looked at). I really
don't know if it would hurt more than it would help.

But... that doesn't mean that I advocate Squeak to stand still
language-wise. I love the fact we got Traits - even though it hasn't taken
off yet AFAIK - anyone using them btw?

regards, Göran