Squeak and Namespaces

Göran Krampe goran at krampe.se
Fri Dec 1 07:59:10 UTC 2006


Hi!

>>From: Göran Krampe <goran at krampe.se>
>>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.
>
> Yes, but here is the difference I see:  Right now we have MCDictionary (ok
> we probably don't, but as an example) and Dictionary.  When I see
> MCDictionary, no problem, I know its for MC.  And when I see Dictionary I
> know it's a pure dictionary.  But with your solution, yes it stays like
> now
> *for the moment*.  But you made this to get used.  Which means the MC
> people
> will want to change MCDictionary to MC::Dictionary.  What happens then?
> MC::Dictionary gets only slightly (to my eyes) uglier, but now all my uses
> of Dictionary become Kernel::Dictionary.  Right?  That's what I don't
> want.

As I posted a minute ago - no, it would stay Dictionary.

>>I agree. And yes, there is a cost. But people seem to think that we have
>>these choices:
>>
>>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).
>
> I'm with you on the complexity of imports.  I know it can really suck in
> other languages.  And in smalltalk I think it would be one of the rare
> things that is *more* problematic then for other languages because you are
> looking at a method at a time.  You would have to put the import
> statements
> somewhere else (I think Andreas suggested with the package) and then
> simply
> remember them since you can't see it anymore.  Or keep two browsers open
> for
> every class you edit.

Exactly. And there are other issues - like for example the fact that
writing a snippet in a Workspace (or any other text area) suddenly needs
to know what imports it is supposed to use...

> So it is a complicated problem end to end.  Of everything I have heard I
> think the Gemstone (I think it was) solution was the best over all.  It
> still has the problems with extra burden for programmer memory but you get
> a
> lot with it at least.
>
>>1. Live on with "manual" namespaces using prefixes that doesn't enable
>> any
>>proper tool support. We have them ALREADY - don't deny it.
>>
>
> Who denies it?  I think the disconnect here is simply:  you see this as a
> huge, almost show-stopper level problem.  I personally see it as a minor
> annoyance that actually gets amazingly close while still looking nice and
> being explicit/obvious (i.e. less burden for the reader, and we all know
> code is read much more then written).  I personally don't want the look of
> (to me) a beautiful language to change for pain I just don't feel.

It sounds like the "look" will be changed dramatically. We are only
stuffing in '::' between the prefix and the rest. It is not a HUGE
difference you know. :)

>>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.
>
> If the solution is right it will have a good chance to get adopted I would
> think.

Hehe, the problem with that line of thought is that "is right" is
subjective. The more complex solution the likelier it will piss off tons
of Squeakers that will stop it dead on squeak-dev.

> Traits was a pretty big change, but it fixed a real problem with
> some huge pain.

Really? A huge pain? I agree that Traits are great etc, but I would not
say that we had "huge pain" before we got them.

> And also, it hasn't changed how most of Squeak looks afaik.

That is just because they aren't used yet. :)

regards, Göran




More information about the Squeak-dev mailing list