I'd rather take the working system that Goran has and allow Gulik to
keep working on his.

Then we can debate the merits of switching to a different (completed) system.

On 9/19/07, Igor Stasenko <siguctua at gmail.com> wrote:
> Just 5 cents.
>
> I don't know, really a reasons why we should keep with obsolete
> doctrine in having global dictionary? Its a barrier in collaborative
> environment which we should remove (and the sooner - the better),
> because if we don't do anything and keep things intact, while squeak
> code base will grow, soon there will be 5% instead of 1% in name
> conflicts and will grow more and more.
> In closed, self sufficient community there no need to have any support
> in namespaces.
> But i hope everyone here wants to see a squeak is a number one
> smalltalk in the world, or we don't?
>
> Giving a simple way to use global names in smalltalk was done for
> convenience of developer. But now, we get to point that each conscious
> developer, each time he needs to create new class should think twice
> what name to give to it, because convenience to him here and now, can
> turn into inconvenience for others later.
> And, obviously, in such situation its more convenient for ALL to use
> namespaces :)
>
> A names locally bound to some Namespace don't change code drastically,
> and code can stay backward compatible (unless you play with well known
> names, like #Array or #Collection).
>
> Most often uses of global names is references to well known kernel
> classes like #OrderedCollection, #Array, e.t.c. If you take any random
> class from any other package, you'll find that number of references to
> it barely beyond 3.
>
> So, i think that converting any userland(i.e. non-core) code to use
> with namespaces is a task for couple of minutes, since before
> conversion we had each unique name = unique class.
>
> There are some problems when moving to namespaces like usage of
> 'Smalltalk at:/at:put:' code. But using reflective hammer we can
> easily get around it:
> - get caller context, get its method, get method's class, get class
> namespace - do name lookup.
> So, if we really want it, we can do it in backward compatible way.
>
>
> On 19/09/2007, Göran Krampe <goran at krampe.se> wrote:
> > Hi Jason!
> >
> > > Hi,
> > >
> > > To keep it short, I've been heading down the same path on my own. So I
> > > should check out your package and see where you are, and maybe same myself
> > > some time. :)  Wonder if it'll break in 3.10.  Thanks for your write-up.
> > >
> > > Jason
> >
> > I started this code in 2004 actually. The issue of namespaces pop up
> > regularly here in Squeak-dev and I try to explain it and push it and tweak
> > it a bit every time the subject comes up.
> >
> > I would gladly see some help with punding on it and fixing some
> > outstanding issues etc. If you are interested (or anyone else for that
> > matter) - email me and/or pop up on IRC (irc.freenode.net, #squeak - I am
> > gokr or gok1).
> >
> > I am going to OOPSLA late october and it would be neat to give it a push
> > until then. My other "labor of love" right now is DeltaStreams, which is a
> > tad related.
> >
> > regards, Göran
> >
> >
> >
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
>
>