Squeak and Namespaces

Göran Krampe goran at krampe.se
Thu Nov 30 12:04:00 UTC 2006


>> > The problem comes if we determine there is a much better way to do
>> this.  We
>> > can't just pull the namespaces out because then you will have 30
>> classes
>> > named "Dictionary" and so on.  You will have to either touch them all
>> or run
>> > some script that appends the namespace on the front of the class and
>> then
>> > pull namespaces out.  I don't see either of these as doable, so I
>> would
>> > expect that once namespaces are in as default for a couple of years
>> that is
>> > what we are going to have from now on.
>>
>> Eh, no not really. Today without my solution MCDictionary has the name
>> #MCDictionary.
>
> You just said "no", and then repeated J J's post in your own words.  ;)

In some sense yes. :) But I tried getting the subtle differences across -
like that the name of MCDictionary is not its short name with my solution
being in - it is the fully qualified name.

So there is AFAICT no difference from the current state - when we have
MCDictionary.

> In short: you can add hierarchical names with no immediate cost,
> but once people use it, it would be a much larger cost to go back.
>
> While, I like hierarchical naming in general, there is no denying that
> there are plenty of issues to consider.
>
> -Lex

I agree. And yes, there is a cost. But people seem to think that we have
these choices:

1. No change at all leaving us without Namespaces as it has always been.
We don't need no darn Namespaces!

2. Adding my solution now that gives us Namespaces that don't seem so
impressive to all the language scientists (hey, no imports? It must suck).

3. Wait for some "stronger cool advanced" solution coming soon solving all
problems known to man kind regarding naming, dependencies, modules etc.

When in fact we IMHO probably have these choices:

1. Live on with "manual" namespaces using prefixes that doesn't enable any
proper tool support. We have them ALREADY - don't deny it.

2. Fix prefixes so that they can at least be used as proper Namespaces and
enable tool support and what not. It is just an improvement on what we
ALREADY have.

3. Wait forever for "stronger cool advanced" solutions that will be
presented, shot down and never enter the official Squeak. And during this
perpetual wait we will still be using crappy prefixes, while arguing to
death on squeak-dev about different models more incomprehensive than the
next.

Wanna bet? :)

regards, Göran

PS. To all recent Squeakers - Namespaces is a well known squeak-dev killer
subject. It pops up EVERY year, creates tons of posts and never any real
changes. I wrote my solution more than 2.5 years ago!!! And that sure
wasn't the first time this was discussed - remember Squeak 3.3alpha?! Or
Dan's environment experiment which predates even that? Don't think this is
anything new, it is just a recurring cycle. Lord knows how the hell we got
Traits into 3.9 - it is a bloody miracle. :)




More information about the Squeak-dev mailing list