Hi folks!
I just typed this in, longish but hopefully enlightening, forgive me for any typos etc.
regards, Göran ------------ I agree, syntax is not really important. And we have already discussed it AT LENGHT at earlier occasions. To all of you out there that think this is the *first* Namespace-discussion on Squeak-dev - you have no idea... :)
Compile time binding vs late binding: Currently we have compile time binding of class names, I think moving away from that as the "default" is too much of a change. And at the times we want to do late binding we can already use obvious Smalltalk code (in both our proposals): MyNamespace at: #Array
Let me try to explain a bit about my proposed solution (and yes, it is on SqueakMap and *works* almost completely, updated for 3.9 IIRC):
I have written about it on numerous occasions and every time it feels like a lot of people either misunderstand it, don't think it *is* a namespace solution at all, don't even try to understand it or all of the above. :) I am not sure why, but I think it has at least *partially* to do with people being so fixated on how "other languages do it" that they can't even begin to consider an alternative approach. If you read this, please try to open up your mind and consider that there ARE other ways to do it. :)
Ok, (rubbing head to come up with the ultimate pedagogical approach), let's begin with a few "Intentions" with this proposal:
- Simple. I mean, dead simple. :) - Backwards compatible. Tools should work etc etc. - Not disrupt the "feel" of Smalltalk. Read more below.
Now... Michael is IMHO implementing a rather "regular" namespace solution, as so many others have done or tried doing over the years. That may be fine - and from what I know he is doing it as part of a larger project so he probably have good reasons for its design. My proposal is solely aimed at being a lightweight-just-enough-solution only aimed at Squeak and its community and not rooted in any other project. In other words - there is NO other use of my code and effort than getting it eventually accepted in Squeak - otherwise it is totally wasted. ;)
Let's look at "Simple" first. In my proposal I am proposing that we "go with the flow" and evolve what we already have. What *do* we have then? We have a shared global space (SystemDictionary) and other spaces created by various participants in our community (prefixes). Examples are WA for Seaside, SM for SqueakMap and so on. Let's consider that for a second - we actually *already have* a Namespace solution in place which works! Prefixes. I can hear people thinking "Is he on crack or what, that's not namespaces..." - but I challenge you: Why not?
Just because lots of people over the years have for various reasons decided to make namespaces==package (or some other concept) does not mean that a Namespace IS a package or any other source code or deployment entity. A Namespace is "just a space of names" - a Dictionary simply. Please agree with me on that. :) A named space that is a cooperatively maintained set of unique names.
If we agree on this then the scope of problems we are trying to solve is made much smaller and comprehensible:
- Allowing duplicate names in an image. - Being able to write short names and read short names. - Being able to manipulate namespaces like remapping or moving names between them etc.
It does not deal with deployment units, method overrides, source code management etc etc!
Now, let's look at the prefixes used today then:
- It is not hierarchical! It is simple "a bunch of named buckets". But that is exactly what was needed! So saying that namespaces MUST be hierarchical is ignoring the fact that what we have today actually works. - Binding is compile time, just as with globals. Hey, WAComponent is of course also a global, since the solution today is just plain prefixing.
I am proposing:
- Allow "::" (or hey, any other nice separator that we can agree on - it is NOT that important) in global names. This is a very small change and we have done it (Andreas and I) and it works. - Implement class Namespace and let it act just like a Dictionary and let us create one instance "per prefix" automatically. This is the reification part of my proposal so that:
Fruit::Orange == (Smalltalk at: #Fruit) at: #Orange Fruit::Orange == Fruit at: #Orange Fruit class == Namespace
Thus our namespaces are globals and we can easily do nice dynamic lookup using "Fruit at: #Orange" if we like. We can also easily check for Namespaces being there with "Smalltalk at: #Fruit ifAbsent: []" and we can manipulate our namespaces and classes within them etc. IMHO the obvious Smalltalk way - I presume Michael's solution in this respect is similar.
BUT... Andreas advised me *strongly* to let my Namespace instances delegate to Smalltalk (the SystemDictionary) because otherwise tons of code will break. So my Namespace instances behave like Dictionary but actually don't hold anything at all! The class is *still held in Smalltalk* just like before:
(Smalltalk at: #Fruit::Orange) == Fruit::Orange
At this point people may be confused but it all boils down to this usage pattern:
- If you want to have a class Apple in your own namespace "Fruit", just name it "Fruit::Apple"! It is that simple. - If you want to move it, just rename it! The Namespace instances I describe are automatically created and maintained. - If you want to use it, just type "Fruit::Apple" (because hey, that is the name of the class!) but of course, you don't want to type all that so fine, just type "Apple" and it will automatically work! Different things will happen then: - If there is no other Apple in your image it will just work. Apple. No prefix needed. This covers 98% I guess. - If there are multiple Apple, Squeak will ask you which one you mean (nice popup menu) and autoexpand it in place! - If there are multiple Apple BUT one of them is in your LOCAL namespace (=the namespace of the class you are editing) then it will work just fine with the short form, the local Apple is chosen instead of the others. This covers perhaps 70% of those last 2%. :)
Let me repeat that: If you consider what I wrote above you will only write (and read) fully qualified names (Fruits::Apple) if and only if there are multiple Apples in your image (and I bet there aren't - 98% (?) of all classes have most likely unique short names!) AND the method you are editing is in a class in a namespace that does NOT have one of them (it is not local).
Please let this sink in. This means we have NO IMPORTS and we still don't need to write or read qualified names! How is this done?
Let's compare to Java. In java we avoid typing long names by typing the paths once at the top of the file - the imports. Then we can use short names in the rest of the file. This is classic. Anyone who knows Eclipse and the alt-shift-o key combo knows that you ever hardly edit the imports section because Eclipse *will do it for you* if you press that key combo! So in Eclipse/Java you can emulate my proposal by pressing alt-shift-o every minute (perhaps add a background process that does it? :)) and only type short names! Yep, same effect. The only difference is that instead of encoding the qualified names by splitting out the tedious long paths into an imports section - in my proposal we simple *don't*! We use qualified long names ALL THE TIME in the source. You can do that in java too - but it would look like hell and be awful to type.
The trick is to let the source use fully qualified names at ALL TIMES and just hook into the source code pane rendering code and the source code editing code and make sure the tools "render" short names and accept short names when being typed. Aha! So the trick is in the tools. The actual source code is JUST LIKE BEFORE. And that is why my proposal is so darn backwards compatible.
And the simplicity of this is very powerful. Every class reference is fully qualified. If you add ten Apples in your image the old references will still refer perfectly to the Apple they intended (Stephane's use case), but suddenly they will *render* fully qualified since you otherwise would not know which one they refer to. And if you remove 9 Apples the references still around will suddenly render *short* again.
Another example, if you move a class from one namespace to another - that is equal to a class rename operation - and Squeak already handles renames rather gracefully - by offering all methods it is referenced to that you can change them. Or using RB it can fix the references for you - I haven't tested this but I bet this works PERFECTLY FINE with my proposal!
I hope my ramblings here have shown that my proposal is indeed VERY SIMPLE, has NO IMPORTS, still avoids typing and reading of long names, still are REAL namespaces (you can make an Apple and so can I) and is very backwards compatible (hey, even old fileout formats should work just fine and Monticello and all our other tools).
But what did I mean with "Smalltalk feel"? I meant that in Smalltalk we don't have "modes". We can type a snippet of code anywhere and just run it - the only thing that is context sensitive is "self" so to speak. But if we start messing with java-ish conventional namespaces with imports we suddenly have lost that "loving feeling" - we will have lots of "modes". The snippet will bind and behave very differently based on where I run it. Which class? What imports does it have? What does OrderedCollection actually bind to? And how does a Workspace work? And what imports does the debugger have and the inspectors and all other text panes? Please consider this.
regards, Göran
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
On 9/19/07, Göran Krampe goran@krampe.se wrote:
Hi folks!
I just typed this in, longish but hopefully enlightening, forgive me for any typos etc.
regards, Göran
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
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
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.
I'd rather take the working system that Goran has and allow Gulik to keep working on his.
+1 on Goran's proposal!
Ramon Leon http://onsmalltalk.com
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.
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.
It wouldn't be a Goran image, it'd be a standard squeak image, since the whole point would be to include that fix in the base image to allow us to at least take one tiny step in the direction of a solution that formalizes what we're *already doing with class prefixes*. Why? Because no one will accept any other solution, look in the archives, this battles has been fought many times.
Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community doesn't want it, just wait, you'll see.
Ramon Leon http://onsmalltalk.com
On 9/20/07, Ramon Leon ramon.leon@allresnet.com wrote:
Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community doesn't want it, just wait, you'll see.
I'm aware of this. I think it's a shame because almost every other programming language supports encapsulated namespaces. Even C does to some extent - if you don't #include code, you can't use it.
I plan to keep my namespaces packages available and maintained on the PackageUniverse so it's there if people want to use it. It also happily co-exists in an image next to the SystemDictionary, so no great sacrifices are made to use it. The main issue is that I gave up trying to get Monticello to save Namespaced code[1], so you need to use my own proprietary packaging format.
Gulik.
Hi,
On 9/20/07, Ramon Leon ramon.leon@allresnet.com wrote:
Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community doesn't want it, just wait, you'll see.
This is a Good Thing. After all, how many poeple are ever going to write Traits ?
All the critics are saying is that the solutions, as presented, are flawed.
Hi all!
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.
It wouldn't be a Goran image, it'd be a standard squeak image, since the whole point would be to include that fix in the base image to allow us to at least take one tiny step in the direction of a solution that formalizes what we're *already doing with class prefixes*.
Yes, very well put. And also, check: http://swiki.krampe.se/gohu/35
...where I describe the minimal fix - module testing extensively, but as you can see it is TINY. So if you happen to be sitting with an old Squeak image and want to load new code using ::-names, just smack that changeset in and go.
Why? Because no one will accept any other solution, look in the archives, this battles has been fought many times.
Again, very well put.
Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community doesn't want it, just wait, you'll see.
And also - all people rejecting any "real" solution (although I tend to argue with that choice of word) - are not entirely wrong either.
I mean, we aren't really *suffering* here. :) It just happens to be a "nagging itch" that we - as developers - like to approach somehow.
Also, note that given my proposal you CAN actually "tack on" additional mechanisms like for example imports (for context dependent resolving). I just tend to think they aren't really needed.
regards, Göran
Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community
doesn't want
it, just wait, you'll see.
And also - all people rejecting any "real" solution (although I tend to argue with that choice of word) - are not entirely wrong either.
regards, Göran
By *real* I mean other overly complicated hierarchtical package managing, code securing, auto class rename on importing, whiz-bang solutions that 99% of us don't really need (obviously since we don't have that now). I just want the damned browser to hide the prefixes (aka manual namespaces) like it formats the code, a simple aesthetic preference. Nice, simple, keeps Smalltalk as is, one global namespace, no imports, no ambiguity, just a smarter view and a change small enough, with so little object to, that it might actually happen within my lifetime. As it stands, it's by far the most pragmatic solution on the table.
Ramon Leon http://onsmalltalk.com
Hi Ramon!
Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community
doesn't want
it, just wait, you'll see.
And also - all people rejecting any "real" solution (although I tend to argue with that choice of word) - are not entirely wrong either.
regards, Göran
By *real* I mean other overly complicated hierarchtical package managing, code securing, auto class rename on importing, whiz-bang solutions that 99% of us don't really need (obviously since we don't have that now). I just want the damned browser to hide the prefixes (aka manual namespaces) like it formats the code, a simple aesthetic preference. Nice, simple, keeps Smalltalk as is, one global namespace, no imports, no ambiguity, just a smarter view and a change small enough, with so little object to, that it might actually happen within my lifetime. As it stands, it's by far the most pragmatic solution on the table.
Ramon Leon
My check is in the mail, is 100 enough? Ehm, oops, I just mailed this to the list.... ;)
Let me just point out a few current issues that we need to fix:
- Currently I render class references by using a *full parse* of the method and fixing up the global references. This is of course the REAL way to do it and only touches REAL global references and not stuff in comments or what not. But it punishes browsing code of course, it feels slower. I haven't looked closely at it - perhaps I did something stupid, but I also toyed with hooking into Shout which obviously also is parsing code and does it fast!
- Some tools are not caught by my low level hook, like method versions browser for example. Need to catch.
- I have a vague recollection of filing out not properly working, I probably shot myself in the foot somehow.
So... it is definitely not yet perfectly ready to go in - but with a bit of work I think it would easily be.
regards, Göran
I just want the damned browser to hide the prefixes (aka manual namespaces) like it formats the code, a simple aesthetic preference.
The only trouble is the problem is still not totally solved; you can still have a conflict.
Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff.
How many possible two-letter prefixes are there; 26 squared is only 676 namespaces and you know they won't all be used anyway. Not nearly enough for a large community developing a large variety of frameworks and applications with the general-purpose tool.
So I guess we'd could all start using larger prefixes to ensure we could grow to a very large community with Göran's approach. Tell you what, I'm gonna stay slick with my two-letter prefixes but Lukas, please rename all your Magritte classes to use a longer one, ok?
Ha ha, seriously, I don't see it necessarily as a problem *for me* as long as the tools were *really good* at hiding and auto-prefixing-on-save. However, I dubious that the entire community would be able (let alone willing) to engage in this sort of "collaborative cooperation" when individual project work beckons. No one should really have to, honestly.
Sorry Göran, I guess I'm starting to waffle right back to my original desired solution of three years ago:
> auto class rename on importing
This could potentially be THE simplest, and most fool-proof solution (other than Craig Latta's NAIAD, perhaps). Make this work and we don't seem to need anything else. And it's a solution that is in the dynamic, malleable spirit of Smalltalk as well.
On 9/20/07, Ramon Leon ramon.leon@allresnet.com wrote:
Any "real" namespaces solution will eventually be rejected because it's not a small change and a vocal part of the community
doesn't want
it, just wait, you'll see.
And also - all people rejecting any "real" solution (although I tend to argue with that choice of word) - are not entirely wrong either.
regards, Göran
By *real* I mean other overly complicated hierarchtical package managing, code securing, auto class rename on importing, whiz-bang solutions that 99% of us don't really need (obviously since we don't have that now). I just want the damned browser to hide the prefixes (aka manual namespaces) like it formats the code, a simple aesthetic preference. Nice, simple, keeps Smalltalk as is, one global namespace, no imports, no ambiguity, just a smarter view and a change small enough, with so little object to, that it might actually happen within my lifetime. As it stands, it's by far the most pragmatic solution on the table.
Ramon Leon http://onsmalltalk.com
The only trouble is the problem is still not totally solved; you can still have a conflict.
Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff.
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
How many possible two-letter prefixes are there; 26 squared is only 676 namespaces and you know they won't all be used anyway. Not nearly enough for a large community developing a large variety of frameworks and applications with the general-purpose tool.
Doesn't matter, see above.
So I guess we'd could all start using larger prefixes to ensure we could grow to a very large community with Göran's approach. Tell you what, I'm gonna stay slick with my two-letter prefixes but Lukas, please rename all your Magritte classes to use a longer one, ok?
If you don't have to type them when working within the package, I doubt you'd care that much.
Ha ha, seriously, I don't see it necessarily as a problem *for me* as long as the tools were *really good* at hiding and auto-prefixing-on-save. However, I dubious that the entire community would be able (let alone willing) to engage in this sort of "collaborative cooperation" when individual project work beckons. No one should really have to, honestly.
But we already do, the tools just aren't smart enough to allow us to hide it. Göran's proposal just takes current practice, prefixing, and adds tool support to make it a much nicer solution. We'd get a lot more mileage out of prefixing with tool support.
Sorry Göran, I guess I'm starting to waffle right back to my original desired solution of three years ago:
> auto class rename on importingThis could potentially be THE simplest, and most fool-proof solution (other than Craig Latta's NAIAD, perhaps). Make this work and we don't seem to need anything else. And it's a solution that is in the dynamic, malleable spirit of Smalltalk as well.
And such a big change that it isn't likely to be implemented, just talked about endlessly until everyone gives up and the status quo is maintained. The thing that makes his proposal so nice is that it's just a tiny change to make the status quo good enough to let us actually have a working solution while everyone argues endlessly about something fancier.
I see three options that are likely
1. Do nothing (most likely) 2. Do very little, Göran's approach, formalize and add tool support to *current prefixing practice* (possible, but unlikely) 3. Do a huge change and add full namespaces and get rid of the big bad global SystemDictionary (when hell freezes over in this community)
So, being annoyed by seeing and typing prefixes constantly, and also being pragmatic and wanting to see a solution get accepted by the community, 2 seems the only viable option. As cool as 3 might be, it just isn't going to happen. Maybe I'm wrong, but that's my impression.
Ramon Leon http://onsmalltalk.com
Well I have to admit, there seems to be no harm in doing Göran's proposal. It's an incremental step forward that should buy us a LOT of time, probably as much as we'll ever need. Also, like he said, does not preclude migrating to any other namespace solutions in the future.
That alone is enough to win my vote of support.
On 9/20/07, Ramon Leon ramon.leon@allresnet.com wrote:
The only trouble is the problem is still not totally solved; you can still have a conflict.
Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff.
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
How many possible two-letter prefixes are there; 26 squared is only 676 namespaces and you know they won't all be used anyway. Not nearly enough for a large community developing a large variety of frameworks and applications with the general-purpose tool.
Doesn't matter, see above.
So I guess we'd could all start using larger prefixes to ensure we could grow to a very large community with Göran's approach. Tell you what, I'm gonna stay slick with my two-letter prefixes but Lukas, please rename all your Magritte classes to use a longer one, ok?
If you don't have to type them when working within the package, I doubt you'd care that much.
Ha ha, seriously, I don't see it necessarily as a problem *for me* as long as the tools were *really good* at hiding and auto-prefixing-on-save. However, I dubious that the entire community would be able (let alone willing) to engage in this sort of "collaborative cooperation" when individual project work beckons. No one should really have to, honestly.
But we already do, the tools just aren't smart enough to allow us to hide it. Göran's proposal just takes current practice, prefixing, and adds tool support to make it a much nicer solution. We'd get a lot more mileage out of prefixing with tool support.
Sorry Göran, I guess I'm starting to waffle right back to my original desired solution of three years ago:
> auto class rename on importingThis could potentially be THE simplest, and most fool-proof solution (other than Craig Latta's NAIAD, perhaps). Make this work and we don't seem to need anything else. And it's a solution that is in the dynamic, malleable spirit of Smalltalk as well.
And such a big change that it isn't likely to be implemented, just talked about endlessly until everyone gives up and the status quo is maintained. The thing that makes his proposal so nice is that it's just a tiny change to make the status quo good enough to let us actually have a working solution while everyone argues endlessly about something fancier.
I see three options that are likely
- Do nothing (most likely)
- Do very little, Göran's approach, formalize and add tool support to
*current prefixing practice* (possible, but unlikely) 3. Do a huge change and add full namespaces and get rid of the big bad global SystemDictionary (when hell freezes over in this community)
So, being annoyed by seeing and typing prefixes constantly, and also being pragmatic and wanting to see a solution get accepted by the community, 2 seems the only viable option. As cool as 3 might be, it just isn't going to happen. Maybe I'm wrong, but that's my impression.
Ramon Leon http://onsmalltalk.com
"Chris Muller" asqueaker@gmail.com writes:
Well I have to admit, there seems to be no harm in doing Göran's proposal. It's an incremental step forward that should buy us a LOT of time, probably as much as we'll ever need. Also, like he said, does not preclude migrating to any other namespace solutions in the future.
That is an important consideration. If it is truly incremental, then that is a really nice property.
However, is it really? How will we migrate forward to a hierarchical system where Array is at Collections::Core::Array instead of at Collections::Array ? There will already be code everywhere using Collections::Array .
This all sounds very hasty to me. Instead of endlessly evaluating a quick and dirty scheme, how about the enthusiasts get together and make a system where:
1. Baby code in a starter image can mostly ignore namespaces.
2. A full hierarchy is available, not just one level.
3. Import lists are localized.
4. The source code does not need automatic rewriting in order to look nice.
This is a doable list of properties, and I believe it could be solved faster than trying to convince everybody to use something incomplete.
For bonus points, don't forget to check on the existing systems like GST's and VisualWork's, and don't forget to poll the major producers of Squeak code about what they want.
Lex
That is an important consideration. If it is truly incremental, then that is a really nice property.
However, is it really? How will we migrate forward to a hierarchical system where Array is at Collections::Core::Array instead of at Collections::Array ? There will already be code everywhere using Collections::Array .
He's not saying everything in the image needs to be converted to this, all the core classes can stay as they are now, global. The :: will mostly enable *new* code or code you choose to rename to use browser aware prefixes that can be hidden.
This all sounds very hasty to me. Instead of endlessly evaluating a quick and dirty scheme,
People have been trying to get some form on namespaces in Squeak for several years now. Gorans proposal is quite old, how exactly is that hasty?
how about the enthusiasts get together and make a system where:
- Baby code in a starter image can mostly ignore namespaces.
- A full hierarchy is available, not just one level.
- Import lists are localized.
- The source code does not need automatic rewriting in order to look nice.
This is a doable list of properties, and I believe it could be solved faster than trying to convince everybody to use something incomplete.
For bonus points, don't forget to check on the existing systems like GST's and VisualWork's, and don't forget to poll the major producers of Squeak code about what they want.
Lex
Seriously, if we can't even agree to formalize some minimal tool support for the *existing practice* of prefixing, I can't see that anything else will ever get done.
How many times does the attempt have to fail before everyone sees that these big sweeping hierarchtical/import solutions won't be accepted? Are namespaces in Squeak are just doomed to endless debate resulting in doing nothing over and over again and while we're all stuck with manual prefixes or non-standard add in packages forever?
Ramon Leon http://onsmalltalk.com
On 9/21/07, Chris Muller asqueaker@gmail.com wrote:
Well I have to admit, there seems to be no harm in doing Göran's proposal. It's an incremental step forward that should buy us a LOT of time, probably as much as we'll ever need. Also, like he said, does not preclude migrating to any other namespace solutions in the future.
But it can be harm. Not to pick on traits, but to take it as an example. Have they helped? Andreas at least doesn't think so, and we still haven't seen conclusive evidence that they are going to help as implemented. If they turn out to be a bad idea how are they going to get ripped out again?
And that's something that isn't even getting used that much. The namespaces will probably be used very quickly. I'm surprised there are no packages that depend on them already.
Well, I really don't see much harm. Let's say I decide I want no part of Goran's proposal but many in the community moved forward with it. Now I want to use code from one of the proponents.
The only difference is their classes will be spelled with a :: in there somewhere. I can't dictate how classes are spelled now any less, so what's the harm?
On 10/4/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 9/21/07, Chris Muller asqueaker@gmail.com wrote:
Well I have to admit, there seems to be no harm in doing Göran's proposal. It's an incremental step forward that should buy us a LOT of time, probably as much as we'll ever need. Also, like he said, does not preclude migrating to any other namespace solutions in the future.
But it can be harm. Not to pick on traits, but to take it as an example. Have they helped? Andreas at least doesn't think so, and we still haven't seen conclusive evidence that they are going to help as implemented. If they turn out to be a bad idea how are they going to get ripped out again?
And that's something that isn't even getting used that much. The namespaces will probably be used very quickly. I'm surprised there are no packages that depend on them already.
On Sep 20, 2007, at 8:12 PM, Ramon Leon wrote:
Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff.
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
Actually, you are not forced to use two letter prefixes - you can use ten letter prefixes if you like. But it would get tiresome to type those - unless you created export names. How's that? When you build a package, use long names. But create a subclass of SharedPool with short names for all your classes bound to your classes. So if I create the FlamingWicked package, I would create a FlamingWickedExports subclass of SharedPool with the short names of my classes as class variables and a class initialize method that initializes the elements.
FlamingPoolExports>>initialize Foo := FlamingWickedFoo. Bar := FlamingWickedBar....
Users of my package just add FlamingPoolExports to the PoolDictionaries in the class definition. No tool support required.
-Todd Blanchard
On 21/09/2007, Todd Blanchard tblanchard@mac.com wrote:
On Sep 20, 2007, at 8:12 PM, Ramon Leon wrote:
Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff.
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
Actually, you are not forced to use two letter prefixes - you can use ten letter prefixes if you like. But it would get tiresome to type those - unless you created export names. How's that? When you build a package, use long names. But create a subclass of SharedPool with short names for all your classes bound to your classes. So if I create the FlamingWicked package, I would create a FlamingWickedExports subclass of SharedPool with the short names of my classes as class variables and a class initialize method that initializes the elements.
FlamingPoolExports>>initialize Foo := FlamingWickedFoo. Bar := FlamingWickedBar....
Users of my package just add FlamingPoolExports to the PoolDictionaries in the class definition. No tool support required.
Interesting, what current tools do, when you using two different pools having same name defined in both?
-Todd Blanchard
And such a big change that it isn't likely to be implemented, just talked about endlessly until everyone gives up and the status quo is maintained. The thing that makes his proposal so nice is that it's just a tiny change to make the status quo good enough to let us actually have a working solution while everyone argues endlessly about something fancier.
I see three options that are likely
- Do nothing (most likely)
- Do very little, Göran's approach, formalize and add tool support to
*current prefixing practice* (possible, but unlikely) 3. Do a huge change and add full namespaces and get rid of the big bad global SystemDictionary (when hell freezes over in this community)
So, being annoyed by seeing and typing prefixes constantly, and also being pragmatic and wanting to see a solution get accepted by the community, 2 seems the only viable option. As cool as 3 might be, it just isn't going to happen. Maybe I'm wrong, but that's my impression.
Given the right tools i'll use 3. By having a tool which can import packages from 1 and 2 to 3 , i will use 3 without doubts. And then, if someone really want to use new code then he will be forced to use 3, and so, all current arguments against it will simply step back before a desire to use it. :)
P.S. And i really don't care, do i need to type extra characters for prefix or not. As i said before, usually number of user-land(non core) class references in code is barely beyond 3. So i see no big harm in typing prefix couple times in couple of places. Comparing to benefits of namespaces its a joke.
On Sep 20, 2007, at 9:12 PM, Ramon Leon wrote:
Magritte and Magma already both very nearly use the same prefix, "MA" and "Ma", respectively. It's hard for me to accept, after all this discussion and effort and say Göran's finally makes it into the base image, that I could very easily collide with Magritte unless at least one of us renames a bunch of stuff.
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
I completely agree with this as well - I would have no problem adding longer prefixes to my code, and would make class names more readable when they weren't shortened by the tools...
- Brian
On 9/21/07, Ramon Leon ramon.leon@allresnet.com wrote:
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
I have a question: What is stopping you from using them right now today? Most of what you write is for private use, no? If so you can use namespaces until your hearts content. You could even make scripts to change Magritte and co to switch to the namespaces when loaded into your image, so that you don't have to type the prefixes anymore.
Why do you need this to be in the default image to use it for private code?
I have a question: What is stopping you from using them right now today? Most of what you write is for private use, no? If so you can use namespaces until your hearts content. You could even make scripts to change Magritte and co to switch to the namespaces when loaded into your image, so that you don't have to type the prefixes anymore.
Why do you need this to be in the default image to use it for private code?
The same thing that stop me from wanting to over customize any environment, it makes all your code non standard, harder to share, harder to blog about, setting up new images becomes more work, all because no one wants to install something like Namespaces to just try it out.
Namespaces belong in the core, not as an add on package. Why? For the same reason objects belong in the core and not as an add on package, look at Scheme's situation with objects, add on packages just get you *many* incompatible implementations of something where everyone argues endlessly about which to use.
It's shameful to be forced to manually prefix our class names in what *professes* the be the ultimate object oriented language because every time the issue comes up people come out of the wood works to filibuster every attempt at a solution.
I'm behind Gorans proposal because it's the smallest change possible that seems to make just a tiny bit of progress on an otherwise insurmountable mountain of an issue. Every other proposal is a pie in the sky fantasy not on technical merit, but on the social reality of this community. Gorans proposal is the only one that recognizes the *reality* that a big change just isn't going to happen, no matter how technically brilliant it might be.
Ramon Leon http://onsmalltalk.com
Traits got in.
On 10/4/07, Ramon Leon ramon.leon@allresnet.com wrote:
I have a question: What is stopping you from using them right now today? Most of what you write is for private use, no? If so you can use namespaces until your hearts content. You could even make scripts to change Magritte and co to switch to the namespaces when loaded into your image, so that you don't have to type the prefixes anymore.
Why do you need this to be in the default image to use it for private code?
The same thing that stop me from wanting to over customize any environment, it makes all your code non standard, harder to share, harder to blog about, setting up new images becomes more work, all because no one wants to install something like Namespaces to just try it out.
Namespaces belong in the core, not as an add on package. Why? For the same reason objects belong in the core and not as an add on package, look at Scheme's situation with objects, add on packages just get you *many* incompatible implementations of something where everyone argues endlessly about which to use.
It's shameful to be forced to manually prefix our class names in what *professes* the be the ultimate object oriented language because every time the issue comes up people come out of the wood works to filibuster every attempt at a solution.
I'm behind Gorans proposal because it's the smallest change possible that seems to make just a tiny bit of progress on an otherwise insurmountable mountain of an issue. Every other proposal is a pie in the sky fantasy not on technical merit, but on the social reality of this community. Gorans proposal is the only one that recognizes the *reality* that a big change just isn't going to happen, no matter how technically brilliant it might be.
Ramon Leon http://onsmalltalk.com
Traits got in.
That they did, but were there any alternative implementations to argue over? Traits seems to be the exception rather than the rule. You are right about something though, if Gorans proposal works well, I should be happy loading the packing and just using it.
The problem is, there's more than one package using custom parsers, like the RefactoringBrowser and Shout that I rely on that aren't likely to be fixed unless they have to be, which is why I want something in the main image. Otherwise I'm stuck begging for patches they have no reason to actually support, or trying to fix things myself. If something's put in the core, everyone has to support it.
Like I said previously, I don't actually think anyone's approach will be accepted. I fully expect the status quo to be maintained, I'm just hopeful that eventually, something will get done.
Ramon Leon http://onsmalltalk.com
Because the default image makes me type the longer prefixes. Göran's proposal allows me to just type (and read) the "local" names.
It's really nothing more than delineating the prefix so the tools can make it easier for the human.
On 10/4/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 9/21/07, Ramon Leon ramon.leon@allresnet.com wrote:
We use two letter prefixes because we're forced to see them and type them constantly, with Göran's proposal, it'd be much more common to use Magritte:: or Magma:: as the prefix since you wouldn't be typing it, it'd resolve naturally when you just used the short class name. Granted this doesn't help existing packages with short prefixes, but it'd help new code. If it worked well, I'd sure take the time to rename my code to use it.
I have a question: What is stopping you from using them right now today? Most of what you write is for private use, no? If so you can use namespaces until your hearts content. You could even make scripts to change Magritte and co to switch to the namespaces when loaded into your image, so that you don't have to type the prefixes anymore.
Why do you need this to be in the default image to use it for private code?
Because the default image makes me type the longer prefixes. Göran's proposal allows me to just type (and read) the "local" names.
It's really nothing more than delineating the prefix so the tools can make it easier for the human.
I wish everyone could see just how pragmatic that tiny little thing is and how much mileage we could get out of it without confusing the issue with security, packaging, code loading, all the other issues that keep preventing any progress from being made.
Ramon Leon http://onsmalltalk.com
How would enhanced prefixes work to load several versions of the same classes ?
For Fruit::Orange and Color::Orange, we have the problem that the English word is overloaded but the program entities could perfectly be named OrangeFruit and OrangeColor. Your proposition makes it more practical to invent and work with unique names indeed, but if I understand correctly, your proposal moves the problem of clashes in class names to clashes in prefixes.
For me, name spaces are about differentiating classes that can only have the same name, because they actually are the same concept, only in a different shape.
E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a single image, I'm still stuck because they will both use Seaside:: or WA:: as a prefix. I would need to change the prefix on the fly while filing the code in (or loading it from MC) and, symmetrically, to rename the client classes to use one prefix or the other.
Hi!
How would enhanced prefixes work to load several versions of the same classes ?
For Fruit::Orange and Color::Orange, we have the problem that the English word is overloaded but the program entities could perfectly be named OrangeFruit and OrangeColor.
Sure, if we are AWARE of both we can avoid the clash - but typically we aren't aware of both and get into trouble trying to load a class library or whatever into an image in which we already have an Orange.
Your proposition makes it more practical to invent and work with unique names indeed, but if I understand correctly, your proposal moves the problem of clashes in class names to clashes in prefixes.
Well, the "moves" is a bit harsh - AFAIK most other schemes do in fact have names on their spaces and yes, you can end up with clashes in namespace names too. But that is either more unlikely, solvable with registries OR even better - solvable by remapping, see below.
For me, name spaces are about differentiating classes that can only have the same name, because they actually are the same concept, only in a different shape.
E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a single image, I'm still stuck because they will both use Seaside:: or WA:: as a prefix. I would need to change the prefix on the fly while filing the code in (or loading it from MC) and, symmetrically, to rename the client classes to use one prefix or the other.
Yes and no. :) Yes, you would need (or let us say "be able to"!) change the prefix "while loading" to something else. And no, I don't think you need to fall back on editing and recompiling referencing methods (if that is what you meant by "rename the client classes").
I thought about having some kind of "map" that you can use, like:
WA mapTo: #WA26
...so that references to WA:: from that point on (when compiled) actually are looked up in WA26::.
Or... you can do it like this too:
- Install Seaside 2.6 (into WA::) - Install/compile all code that should be using 2.6. - Rename the WA:: namespace: WA rename: #WA26. (I was actually coding up #rename: today) - Install Seaside 2.8 (into WA:: which now is free) - Install/compile all code that should be using 2.8.
If I am not too rusty this can be done without recompiling anything because the existing bindings can be "rebound in place" so to speak when we rename the WA:: to WA26:: (reusing the same Association instances).
I haven't played around with such "remappings" yet but don't see any big hurdles in making stuff like this work.
Btw, isn't it nice to be able to talk about WA:: (the syntax makes it apparent that I mean "the namespace called WA")? Another nice effect of using ::. Had I written WA. you would instead wonder why I started this sentence with a lower case letter and you would not have understood I was trying to refer to a namespace. :)
Anyway, IMHO the explicit prefixes combined with reified Namespace instances (with some good protocol/code added) should make these things clearly doable and understandable.
regards, Göran
Yes, I suggested this very idea in another of our epic Namespace discussions three years ago.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-April/076859.htm...
Glad to see the idea reconsidered once again!
Hey Göran, if we can dynamically rename, then do we need ANY namespace solution at all then?
- Chris
On 9/19/07, Damien Pollet damien.pollet@gmail.com wrote:
How would enhanced prefixes work to load several versions of the same classes ?
For Fruit::Orange and Color::Orange, we have the problem that the English word is overloaded but the program entities could perfectly be named OrangeFruit and OrangeColor. Your proposition makes it more practical to invent and work with unique names indeed, but if I understand correctly, your proposal moves the problem of clashes in class names to clashes in prefixes.
For me, name spaces are about differentiating classes that can only have the same name, because they actually are the same concept, only in a different shape.
E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a single image, I'm still stuck because they will both use Seaside:: or WA:: as a prefix. I would need to change the prefix on the fly while filing the code in (or loading it from MC) and, symmetrically, to rename the client classes to use one prefix or the other.
-- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org
E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a single image, I'm still stuck because they will both use Seaside:: or WA:: as a prefix. I would need to change the prefix on the fly while filing the code in (or loading it from MC) and, symmetrically, to rename the client classes to use one prefix or the other.
Recall also that method extensions are part of packages too and currently suffer from potential name-collisions just like classes. Unfortunately this is a much harder problem to solve, and reason why I would never try to load two versions of the same framework into the same image; i.e., because different implementations of the same method extension may collide.
Hi all!
E.g., if for some reason I need to load both Seaside 2.6 and 2.8 in a single image, I'm still stuck because they will both use Seaside:: or WA:: as a prefix. I would need to change the prefix on the fly while filing the code in (or loading it from MC) and, symmetrically, to rename the client classes to use one prefix or the other.
Recall also that method extensions are part of packages too and currently suffer from potential name-collisions just like classes. Unfortunately this is a much harder problem to solve, and reason why I would never try to load two versions of the same framework into the same image; i.e., because different implementations of the same method extension may collide.
Indeed! Hehe, so yes, if the package in question has loose methods and any of those differ between the two versions - then you are in trouble. Unless we also start introducing "selector namespaces" (or whatever that thing was called - the one that picks different implementations based on sender - I think Stephen Pair toyed with that a while ago) - BUT... I just see 100% confusion rearing its ugly head.
regards, Göran
On 9/19/07, Göran Krampe goran@krampe.se wrote:
At this point people may be confused but it all boils down to this usage
pattern:
- If you want to have a class Apple in your own namespace "Fruit",just name it "Fruit::Apple"! It is that simple. - If you want to move it, just rename it! The Namespace instances I describe are automatically created and maintained. - If you want to use it, just type "Fruit::Apple" (because hey, that is the name of the class!) but of course, you don't want to type all that so fine, just type "Apple" and it will automatically work! Different things will happen then: - If there is no other Apple in your image it will just work. Apple. No prefix needed. This covers 98% I guess. - If there are multiple Apple, Squeak will ask you which one you mean (nice popup menu) and autoexpand it in place! - If there are multiple Apple BUT one of them is in your LOCAL namespace (=the namespace of the class you are editing) then it will work just fine with the short form, the local Apple is chosen instead of the others. This covers perhaps 70% of those last 2%. :)
This is more or less how you'd interact with my tools too, except that half the steps won't work yet :-).
My thoughts on your proposal, which I'm trying to keep technical rather than judgemental:
* It's a one-way street to adopt your proposal. I assume that file-outs and changesets will have all names contain "::". This means that any non-namespaced image can't use these file-outs, changesets etc.
* I assume that operations you perform on your namespaces such as renaming them will involve the tools modifying the source code for every method that uses that namespace? This isn't exactly elegant.
* 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?
* If non-namespaced code is loaded into the image, the user will need to manually resolve all ambiguous names, of which there will be more of because developers don't need to use class name prefixes any more.
* 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.
* Your proposal doesn't completely solve naming collisions but instead reduce the likelihood of a collision happening. Collisions can still happen, and we still need to collaborate among ourselves to make sure two people don't use the same namespace.
In effect, what you're presenting as a namespaces implementation for Squeak is a way to hide class name prefixes from the developer, with a well-defined prefix format. It doesn't provide code with a particular context to resolve names in, but rather asks the user on a name-by-name basis to resolve ambiguity.
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.
So +0 from me :-). I'd just like to ask you to put an easily-findable comment in the core parts of Squeak you change so that it is possible to remove it.
Gulik.
Hi!
Highly annoying - I had written a long reply and then it went poof into bit heaven. Ok, one more go:
[SNIP]
This is more or less how you'd interact with my tools too, except that half the steps won't work yet :-).
My thoughts on your proposal, which I'm trying to keep technical rather than judgemental:
- It's a one-way street to adopt your proposal. I assume that file-outs
and changesets will have all names contain "::". This means that any non-namespaced image can't use these file-outs, changesets etc.
It is a tiny changeset (4 modified methods and one added in Parser/Scanner):
http://swiki.krampe.se/gohu/35
AFAIK that would be enough. Needs testing of course.
- I assume that operations you perform on your namespaces such as renaming
them will involve the tools modifying the source code for every method that uses that namespace? This isn't exactly elegant.
No, you can manipulate bindings too. This would simple change the reference without touching source or recompiling. Kinda sneaky, but can be done - I am toying with that now.
And of course if we all move to dynamic lookup (using whatever syntax) then the problem is easy. But I think we should allow both static and dynamic references.
- 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. One may argue that the risk of collision would be less in an hierarchical solution, but I tend to think that it is a small price to pay for the greater simplicity.
Regarding changing source code - I think it opens up a can of worms related to SCM and we should not go there.
BUT... (interesting trick coming up, helmet on!) one could argue that since we are *already* "rendering" references we could be even smarter and render remapped references differently:
Fruit::Apple (if in fact remapped to NewFruit::) could render as:
NewFruit(Fruit)::Apple
...or something. This is just "thought provocation" from me - not a real proposal :).
- If non-namespaced code is loaded into the image, the user will need to
manually resolve all ambiguous names, of which there will be more of because developers don't need to use class name prefixes any more.
No, this one is false.
Non namespaced code referencing Apple will resolve to Smalltalk at: #Apple - nothing else. So it would never "accidentally" collide with Fruit::Apple because we ALWAYS store the fully qualified name in the source. So Fruit::Apple is "Smalltalk at: #Fruit::Apple", and Apple is "Smalltalk at: #Apple" - two different class names simply.
Or perhaps you mean when coding *later*? If you have Fruit::Apple and Electronics::Apple and Apple in the image - and type "Apple" - yes, it will ask which one you want. Unless coding in Fruit:: or Electronics::, then it would autoresolve to the local Apple.
Hmmm, trying to recall if I auto resolve to a "short global" if there IS such a global (and no local Apple) - but no, I don't think it does. BUT... this is all just *tool policy* - just set a preference to favor globals - and it will not ask. :)
Let me repeat that: How your typed characters get resolved is a tool issue and can/should be controlled with Preferences.
- 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.
The end result is the same though.
- Your proposal doesn't completely solve naming collisions but instead
reduce the likelihood of a collision happening. Collisions can still happen, and we still need to collaborate among ourselves to make sure two people don't use the same namespace.
Ehm, no, I would not put it that way. Two people can *use* the same namespace - no problem. As long as they actually COLLABORATE and don't *both* create Fruit::Apple! But this is obvious to me - a namespace can be shared, they typically are - they just typically aren't shared with the whole Planet. Sometimes they are only for one developer, sometimes for a whole bunch.
But I guess you meant make sure two people accidentally don't pick the same namespace *name*, right? Sure. But again, we are already there - prefixes EXIST TODAY. We live with it, we have a registry. And if the shit happens - we make sure there are ways around it. This would be quite rare, I don't see it as a problem. And it should be sanitized, we don't WANT multiple namespaces with the same name.
Also... you are saying "collisions can still happen" and YES, I agree. And there is nothing wrong with that - in fact, I think it is an important social mechanism! "Oops, you have also coded up something called SocketStream? Interesting. I bet we should talk and merge or perhaps nuke one of them etc."
This is GOOD. This is what I have been trying to describe as an "optimistic approach" - anticipate and embrace collisions and deal with them when they happen. Instead of letting each developer sit in a sand castle and create tons of Date classes totally unaware that there are in fact others out there.
In effect, what you're presenting as a namespaces implementation for Squeak is a way to hide class name prefixes from the developer, with a well-defined prefix format. It doesn't provide code with a particular context to resolve names in, but rather asks the user on a name-by-name basis to resolve ambiguity.
Not entirely true either. It does have some "smarts" when it comes to resolving - and as I have described, that can be experimented with at will. Today it already auto resolves local Apples - if there is one.
And the way you say "as a namespace implementation" - you are trying to make it sound like a trivial, non-worthy solution and not REALLY Namespaces. Then I humbly ask: What is a REAL Namespace solution? What am I doing that is NOT REAL?
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.
So +0 from me :-). I'd just like to ask you to put an easily-findable comment in the core parts of Squeak you change so that it is possible to remove it.
Gulik.
If it EVER goes in, of course. And if we (I and Matthew) get DeltaStreams fully working you can even revert it :). (btw, revert actually already works)
regards, Göran
On Thu, 20 Sep 2007 01:16:50 -0700, Göran Krampe goran@krampe.se wrote:
Yes, but I have a hard time seeing a solution to this without a registry. One may argue that the risk of collision would be less in an hierarchical solution, but I tend to think that it is a small price to pay for the greater simplicity.
Mmmmmm. Namespace hierarchies....
System.Runtime.Remoting.RemotingConfiguration
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@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. 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
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.
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 this.
My solution is arguably better, in theory, in that it solves a wider range of problems at the expense of being more complex.
Regards, Gulik.
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@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
On 9/21/07, Göran Krampe goran@krampe.se wrote:
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
Now your coming to the good side! :)
On 9/20/07, Michael van der Gulik mikevdg@gmail.com wrote:
- It's a one-way street to adopt your proposal.
Exactly. I haven't seen any evidence that we have the resources to put something in, decide it's bad and take it out again. I mean, traits is only beginning to be evaluated at all.
On 9/19/07, Göran Krampe goran@krampe.se wrote:
Hi folks!
- It is not hierarchical! It is simple "a bunch of named buckets".
That's a hierarchy. Being hierarchical is not about how many levels, it's about the nature of the relationship: is it horizontal (relational) or vertical (hierarchical). I would say "a global space with a bunch of named buckets" is clearly vertical.
Please let this sink in. This means we have NO IMPORTS and we still don't need to write or read qualified names! How is this done?
Well, I have to admit, this part of your proposal has it's appeal. If you switched to a message passing syntax as mentioned before, then you'd get my little vote.
The trick is to let the source use fully qualified names at ALL TIMES and just hook into the source code pane rendering code and the source code editing code and make sure the tools "render" short names and accept short names when being typed. Aha! So the trick is in the tools. The actual source code is JUST LIKE BEFORE. And that is why my proposal is so darn backwards compatible.
<snip>
The snippet will bind and behave very differently based on where I run it. Which class? What imports does it have? What does OrderedCollection actually bind to? And how does a Workspace work? And what imports does the debugger have and the inspectors and all other text panes? Please consider this.
So a solution that imports will make the code "magical" and unreadable, but why can the tools save us in your case, but not in that case? They can of course. The classes could be some kind of off color in the source code if they are non-global, with a pop up showing exactly where the class was taken from. A lot of options are possible for *both* types of solutions, we don't have to over simplify.
squeak-dev@lists.squeakfoundation.org
-
Blake -
Brent Pinkney -
Brian Brown -
Chris Muller -
Damien Pollet -
David Mitchell -
Göran Krampe -
Igor Stasenko -
Jason Johnson -
Jason Shoemaker -
Lex Spoon -
Michael van der Gulik -
Ramon Leon -
Todd Blanchard