> Hi all!
>
> Cees de Groot <cg at cdegroot.com> wrote:
>> On Tue, 15 Feb 2005 08:40:19 +0200, Brent Pinkney
>> <brent.pinkney at aircom.co.za> wrote:
>> > This just seems lacking from the discussion.
>> >
>> Not completely - I've made the point but not in a separate posting, and I
>> threw in lots of stuff to make sure that it wouldn't stand out ;).
>>
>> But, yes, the first discussion should be - do we need namespaces? Why do
>> we need namespaces? A lot of the discussion has an implicit 'yes' to the
>> first question and probably the second question has been answered a long,
>> long time ago but I always find it good to keep asking these questions
>> over and over again, because circumstances, insights, people change.
>>
>> For example, coming from <uh oh...> Java, I though namespaces quite
>> logical. Python, Perl - the other languages I used at the time, also have
>> it. Then I came to Squeak and found it lacking in this area. It hurt. 
>> Then
>> I moved on to VW, and made copious use of its namespace features. When
>> coming back to Squeak, boy was I glad that I was relieved of the burden 
>> of
>> having to think about namespaces! Prefixes rock compared to VW's
>> namespaces.
>
> Now isn't it great then that my proposed solution is actually "prefixes
> done right"? Yes, I am serious. I have started to think that people get
> scared of my solution because I have called it "Namespaces". And I have
> been technical when explaining it. The problem is, people then think it
> is complex. While it is DEAD SIMPLE.
>
> Now - I intend to try to remedy this and simply post a detailed
> description on how you would USE my solution - the end user experience.
> Then all should see that it is EXACTLY as easy as prefixes, in fact - it
> is even BETTER. And technically it is almost identical to prefixes too.
> That will be in another post.
>
> But perhaps you want the ultra-quick-howto? Here it is - the "Very Very
> Complex How To Use Goran's Namespaces":
>
> 1. Instead of naming your class "#PREFIXMyClass" when creating it using
> the class creation template, you do *two* (oh my god) more keypresses
> and type "#PREFIX::MyClass". But don't worry! Those two lost keystrokes
> which might *drastically* lower your Smalltalking productivity and is
> easily saved in step 2 below. Let's jump to step 2!
>
> No wait, I forgot - it is even BETTER! If you first create a class
> category called "PREFIX-some stuff" and then select that category - the
> class creation template looks like this:
>
> Object subclass: #PREFIX::NameOfSubclass
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'PREFIX-some stuff'
>
> ...so you save even more keystrokes because PREFIX is already typed in
> for you by default!
> Ok, now on to the very complicated step 2.
>
> 2. When you want to refer to your class in code - you type "MyClass"
> instead of "PREFIXMyClass". Yes, I know - it is really hard - but that
> is just the way it works! So for every time you earlier typed PREFIX -
> you now save... let's see 1, 2, 3... eh, 6 keystrokes! And for *every*
> reference! Sure, you *can* type the full PREFIX::MyClass if you want to,
> but who would want to type extra characters for no reason? Now, let's go
> to step 3!
>
> 3. Eh... there is no step 3. The End.
>
> Now if this somehow seems complicated to some of you - I don't blame
> you. Namespaces is HARD STUFF. It needs ADVANCED techniques and IMPORTS
> and, and.... well, bah. Not.

That looks good, but is it implementable ? I know technically namespaces 
comes down to name mangling (prefixing) but then there is the look up side 
of things which is more complicated and is an (initial method call) overhead 
although caching overcomes this.

Then there is the real complicated side of things, partitioning Squeak into 
namespaces/modules. This is what will take the time to do correctly. And not 
to break existing code is another big issue.

My hopes are versioning can also be brought in to this allowing multiple 
versions of apps and Squeak to coexist in one image. This would take quite 
alot of work and have to be very well thought out.

Programs should be like flowsers simple and beautiful, but if you really 
look at them on the inside they are actually highly complex. It is the 
complexity that produces the beauty and simplicity.

Aaron