>From: goran at krampe.se
>Reply-To: 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 00:13:51 +0200
>
>Eh, no not really. Today without my solution MCDictionary has the name
>#MCDictionary.
>With my solution it can still be called that, or be renamed to
>#Monticello::Dictionary. Yes, the name of the class is the full name,
>not the short one.
>
>If we then in a while decide my solution sucks... eh, I guess the only
>valid reason I can come up with would be that people think that
>'Monticello::Dictionary' actually looks bad compared to 'MCDictionary',
>then sure, revert those 3 methods it is all about and remove the  '::'
>so that it is now called 'MonticelloDictionary' - or hey, just replace
>'Monticello::' with 'MC' and tada - we are back where we are now.
>
>Renaming classes is not hard, we do it all the time. And if we ever want
>to move away from prefixes to anything else - whatever solution you
>think that we *ever* will be able to agree on ;) - then we would need to
>do the same anyway.
>

But this is my point.  I think many people would use your solution because 
it *is* more natural to be able to just say Dictionary or SystemEditor or 
whatever within your package.  So lets say that someone starts doing a lot 
of research on this in 2 or 3 years and come up with a solution 2 or 3 years 
after that.  At that point I don't think renaming all the classes that will 
be using this will be trivial.  I think it will be a lot of work and thus 
not doable for the base image.  I would just see it as a shame to not be 
able to adopt a new solution because of legacy.

What you said in your other message about it not coming up unless there is a 
conflict was good.  That would make it easier to simply load other projects 
and not worry about conflicts, and then later fix them.  But I just don't 
see it working like that.  I think once namespaces are in they will be used 
whole-sale, and the reason I think that is what you said before: we are 
using them now manually.

I hope I don't sound too negative.  I think you have done great work and it 
is good to be able to load namespaces if you need them at your company.  For 
a company, a quick stop gap is very needed because you have to deliver a 
product in a specific time frame.  But squeak isn't under such constraints, 
so I don't personally see a rush to put something in the image for this.

To be clear, I think your solution is great.  I just disagree with making it 
default in the image.

> > p.s. Does it get the namespace from the category?  If not, then that 
>might
> > be something to think about. :)
>
>The class creation template borrows the category name in some fashion
>IIRC. But it is only a suggestion.
>

Well I don't know.  It sounds like you avoid a lot of the ambiguity by 
simply forcing every class to be explicit if there is more then one with the 
same name.

My thinking with categories was: if there is a conflict then the package 
could automatically resolve to the category it is in, and all classes in 
that category resolve the conflict to mean the class in their same category. 
  The problem with that is that there has to be a way for those classes to 
explicitly reference classes in other packages, and anything not in that 
package must always explicitly reference which class they mean.  There is 
also the problem that some implicit magic happens with conflict resolution.  
So this idea would also introduce new syntax (and thus I wouldn't go for it 
either).

_________________________________________________________________
Get free, personalized commercial-free online radio with MSN Radio powered 
by Pandora http://radio.msn.com/?icid=T002MSN03A07001