Hi all!

As I have hinted on IRC etc I am not at all sure my own proposal from a
few years back is "optimal" - even though I tend to defend it. I *also*
hesitate about the rendering-aspect, like others do, I just haven't seen
something simpler - until now.

The last few weeks I started thinking about an alternative or rather,
complimentary approach. Mike - yes, this post is long too - but it is a
full new proposal so bear with me.

Let me interweave with Jason's post:

> Ok, I've stated my reasons why I don't like Göran's approach, now time
> to give a suggestion myself:
>
> What if namespaces were just objects that behave like dictionaries
> with the key being a string and value being a meta-class?
>
> They could be used as in:
>
> Seaside at: #Component

This actually already works exactly like that in my ::-proposal and yes,
of course we should have a class Namespace and of course instances of
those should behave like Dictionaries as above. This is not new, I presume
most other proposals do the same.

> or perhaps with a special shorthand:
>
> Seaside Component   "maybe Component needs a #?"

This also works in my ::-proposal - or rather, in my dev image! Just added
a DNU handler that does it. Note though that in both these examples the
Namespace itself is still bound at compile time. And also, DNUs are costly
I think, but perhaps neglectible.

This is the "Dan-syntax" btw, and even though I like the "it is just
messages" aspect of it I really do question the readability. But it still
is not a big deal, so it doesn't matter. But newbies will doubtless wonder
what the heck is going on, I promise!

Note though that the interesting bit is *still* compile time bound in both
these examples - the ref to the namespace itself; Seaside - see below.

> This way it is just an object like everything else, with full
> reflection and everything else we love about Smalltalk.  The only
> issue is that this is a pure runtime lookup.  We would probably like
> to have at least the option of it being compile time.
>
> No problem, we just need my other previous proposal:  Macros. :)  Then
> you can make the namespace lookup at compile time with:
>
> ##(Seaside at: #Component)
>
> or:
>
> ##(Seaside Component)
>
> So what do you all think? :)

Well, I would actually consider going in the OPPOSITE direction inspired
by Dan etc. Why not just go *fully late bound*? It would solve lots of
problems - like dynamic remapping of spaces without any recompilation
needed.

But offering dynamic lookup and still using compile time binding TOO -
that defeats the power of it. If we ONLY use late binding then we have new
interesting opportunities. But what about the old code then? Well:

What if we could just turn a normal good old global ref into something
late bound? If we could, then old code would also turn *fully late bound*
when recompiled.

One way to do this is to compile a global ref as a message send so that:

   Array

...compiles *as if* it said:

   Smalltalk resolve: #Array

...or something similar. Then we can actually dynamically figure out if it
should evaluate to "good old Array" or "Jim's new cooler Array" depending
on for example the PI of the sender or any current remappings or whatever!

So in summary you would type:

   Array

...if you want to dynamically resolve a "global", using whatever funkiness
you want. And then you can also use more specific lookup of course:

   Seaside Component

...or of course:

   Seaside at: #Component

So this would first dynamically resolve "Seaside" and then, we ask that
object (hopefully a Namespace instance) to give us whatever it thinks is
#Component.

The reason I started thinking in this direction - getting closer to Dan's
original ideas I presume - was some older postings from Chris which he
pointed to. He more or less wrote that most problems could be solved if we
could dynamically remap packages - or in other words, dynamically put
packages in namespaces of our liking. After hacking on this in my older
proposal I came quickly to the idea that compile time binding sucks. :)

What would above need then? Well, three parts:

1. Hack Compiler and friends. Not that big a deal actually. No new syntax.

2. Implement SystemDictionary>>resolve: in some simple way. The obvious
way is to just do "self at: key", but we could perhaps add a "remap"
mechanism from the start so that you can put "redirections" in place.

3. Implement class Namespace etc, well, my proposal has the approach of
"simulating" Namespaces within SystemDictionary, if someone else has
something better that works - fine. We can even have different such
beasts.

Rendering etc goes out the window, short forms could be used if #resolve:
was made smarter (like look for "Array" in all namespaces and pick first
found), imports can be added on top, if people want to, but is not needed
etc etc.

This sounds even simpler and more backwards compatible than my first
proposal. ;)

regards, Göran