This would mean that file-outs and Monticello packages would contain "::", am I correct? In this case, we can't go back because all source past that point can't be loaded by a non-Göran image.
Gulik.
On 9/20/07, David Mitchell david.mitchell@gmail.com wrote:
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@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@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.