>From: Göran Krampe <goran at krampe.se>
>Reply-To: goran at krampe.se, The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: "The general-purpose Squeak developers 
>list"<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Squeak and Namespaces
>Date: Thu, 30 Nov 2006 13:04:00 +0100 (CET)
>
>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.  
I realize I don't have to *type* it, but I don't want to *see* it.  It is 
line noise for me.

>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.

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.

>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.  Traits was a pretty big change, but it fixed a real problem with 
some huge pain.  And also, it hasn't changed how most of Squeak looks afaik.

_________________________________________________________________
Share your latest news with your friends with the Windows Live Spaces 
friends module. 
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk