I agree with andreas. That's we did not called classboxes package or 
namespace because
they are something else that mix several things and I'm not sure that 
this is good but we will
try :) and the point is not to push that in Squeak.


Yes Andreas, but for the pessimistic approach to succeed
>> everyone must use something that's "guaranteed" to be
>> unique from each other or you run the risk of returning
>> to the very problem you're trying to solve; name collisions.
>> What name would you choose, then, to guarantee this and also
>> address Göran's concern about lengthy, wordy,
>> hard-to-read names?
>
> You guys have all done too much Java lately ;-) One can literally feel 
> how
> confused you are by namespaces and packages. Really, you didn't get my 
> point
> at all. I was *neither* arguing in favour of an optimistic or a 
> pessimistic
> approach - it was Goran who tried to differentiate along those lines.
>
> My point was to keep namespace semantics as simple as possible. 
> Namespaces
> simply should not do on their own what Goran proposed in the 
> "optimistic"
> approach because this is a task for the tools, NOT for the namespace. 
> The
> tools you use can work either way - they may make it simple for you to
> import names which are defined elsewhere (optimistic approach) or they 
> may
> require you to explicitly qualify every last crap (pessimistic 
> approach).
>
> But this has NOTHING to do with namespace semantics. The whole 
> semantics of
> a namespace is: It looks for a name and if that name isn't there it 
> answers
> nil. Period. That's all a namespace has to do. *Then* the compiler can 
> raise
> the appropriate exception and *then* the tools can decide what to do 
> about
> it.
>
>> I'm sorry to jump in like this, but I want to voice my support
>> for Göran's point.  I think he is 100% correct on everything
>> he said about using an optimistic approach.
>
> To repeat: Whether an approach is optimistic or not is in the tools, 
> not in
> the namespace. If the browser says "okay I'm gonna be optimistic" it 
> can
> silently import the name without ever asking you. If the browser says 
> "na,
> today I'm gonna be pessimistic" it will throw an exception and you'll 
> be
> forced to fully qualify whatever you do. The namespaces are entirely
> unrelated to this.
>
>> We survive today without namespaces by leveraging one of Squeaks
>> greatest strengths; the ability for us to tool our image the way
>> we want.  We survive by employing "collision avoidance" measures
>> because we can, and it has brought us a long way to minimizing
>> both the frequency and severity of the problem.
>
> Okay, I'll be very brief here because I could go over the system and 
> point
> out literally *hundreds* of places where we did not "get by" but rather
> where evolution was severely hindred by name conflicts, where we 
> stalled
> (and still do) precisely because of name conflicts. And the way we 
> "get by"
> these days does help nothing to improve the long-term prospects - the 
> "best
> names" are already occupied (Stream, Socket, Button, ScrollBar, Class,
> Object, Array, Collection..........) so you have to resort to worse 
> names.
> Now at some point these are taken too, and then you end up with
> "SimpleButtonDelayedMenuMorph".
>
> These "get by names" make the system *vastly* harder to understand. So 
> we
> "get by" at the cost of clarity, we "get by" by increasing the entry 
> barrier
> of the system - we "get by" by dying in our own excrements.
>
>> I definitely don't want a problem whose frequency and severity
>> is minimized to be "solved" with something that intrudes on me
>> daily, or lessens the dynamic nature of development in Squeak,
>> such as having to stop and specify imports.
>
> Again (and hopefully the last time :-) whether you have to "stop and
> specify" depends on your tools. Namespaces neither have nor should 
> have any
> requirement in this regard.
>
> Cheers,
>   - Andreas
>
>