Hi!
(should have replied to Brad, but for technical reasons I don't have the original posting available)
From: brad fowlow fowlow@pacbell.net On Nov 30, 2006, at 1:52 AM, Göran Krampe wrote:
Note that you don't get penalized in my solution - BUT if you spread your package as open source (to lots of other users) then you will inevitably "pullute" our shared namespace of common short names. We want to be very careful about that pollution - because it muddles our brains.
But that -is- a penalization, especially since it works both ways; you pollute me also. The overall point of the exercise is to facilitate wide sharing and reuse of code, so that's the basis of evaluation... one measure of success is how thoroughly protected we are from everyone else's naming choices.
Those short names are pollution only because of the nature of the solution. If I have to consider carefully whether or not to use a short name for something because it's a pain in the ass when someone else does too, that's a weakness of the namespace design. Maybe a small one, but irksome.
But IMHO this is not a weakness in the Namespace design - it is instead something we can deal with in numerous of ways on the tool side.
For example, I have played around with marking short names as "shy" which would make them not appear in pop up menus and not force other non-shy names to appear qualified. This would then be used for "private" short names - it is like the inverse of an import, a non-export.
The problem is of course where to store this attribute - as a property on the class would be neat but then we get the whole "backwards compatibility problem", or perhaps we can pull an Avi-trick and use some Category convention etc. etc.
But it doesn't *invalidate* the base solution.
If my day-to-day practical choices for nice code that others can happily reuse, without feeling polluted, end up being: a) pick both unique namespace names and unique unqualified names b) status quo - pick distinctive names for everything, via plain old letter prefixing
then it's no longer clear what I'm buying with the colons, except the ongoing chance that anytime my code lands in an image alongside someone else's who had similar naming tastes to me, we'll both be looking at more colons.
Again - this is the NAIVE and SIMPLE approach - if there are multiple short names we present them qualified. But there is no end to the tricks or policies we can pull - for example, today in my implementation I still show "local" references unqualified, because I think that is a good compromise.
OK, that's an exaggeration... but it's a choice. Explicit disambiguation (imports) is mechanism that has a cost: something more to attend to as a programmer. It also has a value: it's part of a proven pattern for strong namespace insulation, with all the grab&reuse freedom that comes with that.
I am unsure what you mean with "insulation" but my solution offers just as "insulated" spaces AFAIK. You can't break code unless you collide with namespace names - and all other systems I know of has that problem too.
If the insulation is porous (for instance, if other people's code can affect, and can change from day to day, what I see in my editor when looking at my code)
But that is YOUR CHOICE. Just turn off the hiding and nothing changes. :) Or we can add another tool setting where you tell Squeak what code is YOURS and it could ignore the other peoples code when deciding if it should hide prefixes or not. Etc etc.
then the proposal doesn't really give me namespaces... it's namespace emulation.
No, it is not emulation. The spaces are separate - your space can never be affected unless you file in code using the same namespace name - just like in Java or whatever language.
But letter-prefixing is just as good as namespace emulation, and it's more honest; it doesn't pretend (especially to newcomers) to be something it isn't. And it doesn't require syntax adjustments or more editor pop-quizzes.
Given that, do the merits benefit allotting a syntax change (a valuable commodity)
Please realize that the "syntax change" you refer to is about allowing $: in *global references*. As both I and Ramon has made clear you can ALREADY create globals/classes with $: in their name (!). Either *that* is a bug or the fact that you later *can't reference them by their name* in your code is a bug.
IMHO calling this a "syntax change" is a bit on the harsh side. Croquet (or is it Tweak?) allowing positional argument syntax - that is a much larger change IMHO.
that could begin to fork the world into ::-dependent and ::-free code?
Hehe, we have tons of other ways of making code "forked" - like depending on Monticello or depending on Traits etc etc. As I have shown we are talking about 4 method mods and one added method. All in all it is (let me count)...
12 added lines and 7 modified lines of code. This is all you would need AFAICT at this moment to have ::-code working, see:
http://swiki.krampe.se/gohu/35
I bet we can make this work in all Squeaks released to date with minimal effort.
Or would it would be better to acknowledge that letter-prefixing is just about as good, and free, and already there, and hold out for a stronger solution without colonizing the code pool in the meantime?
Ah, the "let's wait for something even better" argument. Well, it sure is a killer. :)
Clearly, it's hard to wrangle a namespace change into this system. A somewhat weak intermediate solution that got any uptake could easily become a further moral hurdle that a stronger solution would have to accommodate; two kinds of legacy cases to reconcile, rather than one.
Hehe, yeah... a "weak intermediate solution". So if I make it much more complicated we can call it a Strong Enterprise Industrial Strength Solution? :)
And I think that an environment where changes in unrelated code could change, at any time, what text you see when browsing your own code, will strike people as a bit weird (to put it kindly).
Sure, weird and uncommon must be bad. Let's just turn Squeak/Smalltalk into one of the "other languages" by emulating how they work - that seems better - let's add imports and... hmmm, we could even start putting the classes in files on disk - then it would be much simpler to find those import statements! :)
Sorry for ranting. I am tired. No offense intended, really. And as I have said - I have no high hopes so I don't know why I get worked up all over again. Habit I guess.
regards, Göran