Hi!

> Hi Göran.
>
> This is probably going to be my last post on this issue because I want to
> spend more time actually coding stuff.
>
> On 9/20/07, Göran Krampe <goran at krampe.se> wrote:
>>
>> Hi!
>>
>> Highly annoying - I had written a long reply and then it went poof into
>> bit heaven. Ok, one more go:
>
> No... I spent time analysing it, reading your wiki pages and thinking
> about
> the consequences.

You misunderstood me - I was explaining that my email client crashed and
that I had to write it all once more. :)

>> > * I also assume that to resolve conflicts of the namespace names
>> > themselves,
>> > the tools need to give the namespace a completely new name (which
>> changes
>> > the source code as it's filed in), and to do this you'd need input
>> from
>> > the
>> > user?
>>
>> Yes, but I have a hard time seeing a solution to this without a
>> registry.
>
> My solution solves this by making import lists refer to namespaces in
> packages which are referenced by UUIDs. I'll spare the details until I can
> give you something to play with.
>
>> > * Your proposal still involves the use of a global dictionary
>> containing
>> > all
>> > global variables and classes. In computer science we learn that the
>> use
>> of
>> > global variables should be minimised, and your proposal certainly
>> doesn't
>> > help us in this regard.
>>
>> I disagree. I think this is just an implementation detail. If you can
>> improve it by making Namespace instances hold the Assocations instead of
>> using the trick I am using - then by all means - go ahead! It would be
>> cleaner implementation wise. But Andreas Raab strongly advised me to not
>> take on that "world of hurt" and I believed him.
>
> If you made Namespace instances hold associations, you would have
> accidentally implemented hierarchical namespaces ;-).
>
>> I'm not against your proposal, and it doesn't make the situation any
>> worse
>> > than the current situation except for the filing out issue.
>>
>> Given what I wrote above regarding filing out - do you still think it is
>> an issue? And also - does any OTHER solution do it any better? I don't
>> think so.
>
> Argh. This is blatent provocation. It's a shame I can't resist replying.

I meant "does any OTHER solution handle fileouts/filein in regards to
compatibility any better"?

Finally, let me assure you that I too *wonder* about what would be the
best path forward. I am not totally convinced my proposal is IT - but I do
defend it technically when details about it is discussed.

For example, yesterday I played around with namespace renaming - with or
without touching existing source - and got it almost working in both ways.
And doing this I started wondering about the message passing style etc and
if a solution based SOLELY on that would be better etc. - similar to Dan's
original idea - but possibly WITHOUT the scoping rules etc.

To be blunt, do it like Keith described more or less, instead of writing:

   Fruits::Orange

...we would write:

   Fruits Orange

...or:

   Namespace Fruits Orange

...or if we start fiddling with compiling a global ref to a send to
thisContext, the above two would decompiled be:

  thisContext Fruits Orange

...and:

  thisContext Namespace Fruits Orange

...anyway, the whole idea being getting rid of all statically compiled
global references and solely depend on dynamic lookup. A cool side effect
of the thisContext trick (if at all feasible) would be backwards
compatibility... perhaps. Enough rambling. :)

regards, Göran