My namespace proposal described in Yet Another Try
Michael van der Gulik
mikevdg at gmail.com
Thu Sep 20 21:32:58 UTC 2007
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:
> 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. I just don't like 500-line emails hitting my inbox so I
snipped it. I'm not sure how it is for other people, but I usually read the
short, concise, to-the-point emails and skip over the 500-line monstrosities
because often they're mostly verbage and take ages to read through [present
company excepted :-) ].
> > * I also assume that to resolve conflicts of the namespace names
> > themselves,
> > the tools need to give the namespace a completely new name (which
> > 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
> > global variables should be minimised, and your proposal certainly
> > 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.
Having run out of good technical disapprovings, I can't say much other than
your approach doesn't feel to me like an elegant engineering marvel (which
I'm sure you'd agree) because you're trying to do something in small
evolutionary increments rather than taking a grander vision and think of an
architectural design that solves as many current and potential future
problems as possible. That said, your approach is more likely than my
approach to be adopted by the wider Squeak community exactly because of
My solution is arguably better, in theory, in that it solves a wider range
of problems at the expense of being more complex.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev