Hi!

> On Nov 30, 2006, at 1:13 AM, Göran Krampe wrote:
>
>> Eh, no... But if you look at typical namespace solutions like for
>> example
>> how it works in Java-land - then they suffer from this effect.
>> Everyone
>> happily sits in their own little "pessimistic" sandbox and invents yet
>> another Date, BigNum, Socket or whatever...
>
> There's a difference, I think.  Many of those cases I've seen in the
> world
> are ones where people consciously chose either a) to replace
> or extend a system facility with their own special one to meet
> special needs,

Yes, but that doesn't mean that it would not benefit from merging!

> or b) most commonly, are simply using the most natural
> name for a component of their work - which is often the most
> natural name for someone else's unrelated component of their work.

I agree. But if they are building a piece of software that they want
others to use - typically like we do in Squeak most of the time (open
source stuff) then they also need to take into account that choosing a
name like Component has a price. It might in that case be better to *try*
to choose something more unique or more specific.

> Neither is one in which there is value in assisting in the merging
> of these two classes (whatever it would mean to assist that,
> beyond letting them coexist without any inconvenience,
> which they generally do.)
>
> One of the nice things about working in a namespaced system
> is that you can happily choose short, simple names for the innards of
> your stuff,
> and not  be penalized when other people do the same.

Note that you don't get penalized in my solution - BUT if you spread your
package as open source (to lots of other users) then you will inevitably
"pullute" our shared namespace of common short names. We want to be very
careful about that pollution - because it muddles our brains.

The fact that my solution shows such pollution - makes it apparent to the
developers that it indeed exists - it will hopefully keep it to an
acceptable level.

> This is one of the "how would it play out"  concerns
> I have about the idea of doing away
> with explicit disambiguation (by some sort of import mechanism)...
> in practice, it means all the most likely names I'd like to use for
> this and that
> would be the ones most likely to trigger :: display.... good short names
> for useful internal doobers would be consumed rapidly,
> and I'd find myself seeing and typing far more '::' than I'd like,
> or going back to finding globally unique names for all such things.
>
> -b

There is one small mechanism I added and then managed to remove somehow -
but it would be easy to add again. The idea is that most of the classes in
a package aren't that useful outside of it - they are "private" to the
package. So if you use such common short names for "private" classes -
then you could mark them as "shy". The effect would be that Squeak would
not consider those classes when you type those short names elsewhere - so
they would not cause the popups nor the visual expansion.

Again - this violates the idea with short names being fully disambiguous
(just like local references violates that principle) - but again,
something we could experiment with and might be worth it.

regards, Göran