Hi!

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

Let me just remind you that we *already* have that problem regardless if
my solution gets in or not - in fact - we are even *worse* off. How come?
Because we *already* use "prefixes" but unfortunately in a way that
disables automated renaming. Just look: SMSqueakMap, WAComponent
blablabla...

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

See above.

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

Yes, and let me here note that in my solution ALL references to globals
are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in
the SOURCE. Sorry for the caps, but this is VERY important to realize.

It means that I can load 34 other packages into my image and as long as we
don't have *namespace name* clashes (like two people using the same name
for their namespace) nothing funky will happen in my source. All
references are still perfectly correct.

The only diff is that when I *browse* the code that earlier said
"Dictionary" now may say "Kernel::Dictionary" because my image now also
contains "Joes::Dictionar" and "Schmoes::Dictionary".

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

Yes, again, see above - problem *already* exists.

> I hope I don't sound too negative.

No problem, I just urge you to test it or read how it works. :)

> I think you have done great work and
> it
> is good to be able to load namespaces if you need them at your company.

I don't think addon namespace solutions will ever be used. I wouldn't.

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

Hehe, rush? Are you aware of when I wrote this? Are you aware of how many
posts I have written about it? Are you aware of how awfully many times the
question of Namespaces have come up on the list? It is one of the "deadly
subjects" always causing an explosion of subjective views and always end
in nada.

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

Note that I thought you meant in what namespace a class is *created*.

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

This mechanism of "local" references is in my solution. So yes, if a
method in Foo::Bar refers to Foo::Boo it will be enough typing "Boo" and
it will render as "Boo" even though you have 100 other Boos in your image.
But it will be "Foo::Boo" in the actual source - as always. Because that
is the name of the class.

Note that these "policy" is nicely encapsulated in a single class - just
check the code. We can play with different rules for this - but I agree -
"local references" is a special case in which we can "guess" for the user.
If he really wants "Blooper::Boo" then he will just have to type that.

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

Not sure what you mean.

regards, Göran