Hi.

Göran gave a demo of the namespace system at a SWESUG meeting, and its was clean and easy to understand. You just name your classes as if you would have prefixed them, like this:

Prefix::ClassName

The tools hide the prefix unless it is needed to disambiguate a name. There is no need to use the namespace prefixes, the namespace system works fine together with the existing global namespace.

Would be a good idea to put this into the next release.

Best, Micke

On 11/21/06, Bert Freudenberg bert@freudenbergs.de wrote:

On Nov 21, 2006, at 17:32 , Aaron Reichow wrote:

...

Ahoy!

I know this might sound like a naive question... But why haven't we implemented namespaces yet? I'm sure there have been some attempts- but what is the status of namespaces in Squeak?

You can download the latest incarnation of Namespaces from Squeakmap

    http://map.squeak.org/package/f88f4752-c4a5-42bf-a613-f7d2a4f48cff

There has been a lot of discussion, but I think most agree now that this is such a simple approach that it might be worth adopting. There is a presentation somewhere explaining it, I'm sure Göran will dig it out if nobody beats him to it.

• Bert -

-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Tuesday, November 28, 2006 2:55 PM To: The general-purpose Squeak developers list Subject: Re: Squeak and Namespaces

+1

• Bert -

+1 more

Ramon Leon http://onsmalltalk.com

Actually, that is the beauty of the proposal. Colons are already allowed unquoted in a symbol. #My::Class is valid right now. In this proposal, the compiler knows *nothing* about namespaces. It just permits a colon in a global identifier. It's the only syntax change.

- Bert -

On Nov 28, 2006, at 23:30 , Klaus D. Witzel wrote:

Please consider an other character, other than the colon. Someone already made a mistake when inventing resend.thisAndThat so that the compiler (and the user) has to disambiguate the syntax, like in, example.doThisAndThat.

In Smalltalk colons belong to arguments and keywords, not to namespace expressions. Remember the white space problem with the minus sign / minus binary selector?

Besides of that, here's my +1

/Klaus

P.S. IMO it's overdue that · – — … and friends make their way into regular syntax diagrams and parsers,

• http://en.wikipedia.org/wiki/

List_of_XML_and_HTML_character_entity_references

On Tue, 28 Nov 2006 22:55:12 +0100, Bert Freudenberg wrote:

...

+1

• Bert -

On Nov 28, 2006, at 22:52 , Mikael Kindborg wrote:

...

Hi.

Göran gave a demo of the namespace system at a SWESUG meeting, and its was clean and easy to understand. You just name your classes as if you would have prefixed them, like this:

Prefix::ClassName

The tools hide the prefix unless it is needed to disambiguate a name. There is no need to use the namespace prefixes, the namespace system works fine together with the existing global namespace.

Would be a good idea to put this into the next release.

Best, Micke

On 11/21/06, Bert Freudenberg bert@freudenbergs.de wrote:

...

On Nov 21, 2006, at 17:32 , Aaron Reichow wrote:

...

Ahoy!

I know this might sound like a naive question... But why

haven't we

...

implemented namespaces yet? I'm sure there have been some attempts- but what is the status of namespaces in Squeak?

You can download the latest incarnation of Namespaces from Squeakmap

    http://map.squeak.org/package/f88f4752-c4a5-42bf-a613- 

f7d2a4f48cff

There has been a lot of discussion, but I think most agree now that this is such a simple approach that it might be worth adopting. There is a presentation somewhere explaining it, I'm sure Göran will dig it out if nobody beats him to it.

• Bert -

I agree with Andreas. Funny but true. This is so important that you noticed that I even break my silence....

Stef

PS: I have been working with VW recently and I really found namespaces getting in my way all the time. Also the integration of namespaces in VW is badly supported at the refactoring level and other tools. So this is often a pain.

PSPS: We have been thinking a lot of this issue and I'm even unsatisfied with what I thought would be interesting: package import level where each class live happily in a package (the package resolves the import) and the programmer does not see namespace except at the boundary when declaring imports but I finally do not like that solution because the cost is too big for the gain. I would like to see a real system develop with it and see the pros and cons before really been sure. So certainly a PhD topic.

On 29 nov. 06, at 09:14, Andreas Raab wrote:

Bert Freudenberg wrote:

...

Actually, that is the beauty of the proposal. Colons are already allowed unquoted in a symbol. #My::Class is valid right now. In this proposal, the compiler knows *nothing* about namespaces. It just permits a colon in a global identifier. It's the only syntax change.

Is that really true? I haven't looked at the code in a while but Goran used code that I had originally written and that code most certainly wasn't just permitting colons in a global identifier. What it did do was introducing explicitly scoped variables and the result of Foo::Bar would depend on what is stored in Foo's scope under the name of #Bar and not on what is stored under Smalltalk at: #'Foo::Bar'. Of course, these two can be made the same by using the same association but that's still quite a bit different from just permitting colons in global names.

Generally speaking, I'm -1 on the proposal, mostly because what the proposal doesn't achieve is to make a real step towards enabling scalability of development (which to me is really what we're after). That's because the *author* of some code still needs to find unique names (prefixes) that do not conflict with the rest of the world and that a "change of prefix" becomes very, very expensive because it's literally like renaming all of the classes at once (and consequently breaking all of the code that uses any name from that "prefix space").

So basically you're trading the probability of conflicts (reduced due to the increased length in names) with the severity of conflicts (increased since changing the prefix is more expensive). It's an incremental approach that shifts tradeoffs but doesn't do anything to address the problem on a more fundamental basis (in all fairness, Goran never claimed it did but it's important in this discussion to understand what this proposal does and doesn't do to assess the impact of a change).

But since it's "only" an incremental shift in tradeoffs I wonder if a language change (with significant costs for compatibility) is really justified. It seems to me that the practical gain is fairly minor and there is little motivation that I can see for anyone with a "serious" project to adopt this solution given that it will neither be portable nor backward-compatible. Put on top that the proposal deliberately doesn't take a stand on any general modularity issues (visibility, dependencies), then what exactly does one gain?

To me the basic question here is: Is the prefix pattern so pervasive (and so problematic) that it deserves a special syntactic representation? Without taking a stab at the "real" problem (scalability of development) my answer is: No. It's a clever hack but nothing that I would loose sleep over if it weren't there (and I won't loose sleep over it being there either but I'd like us to be clear about what we're trying to achieve with adopting it).

Cheers,

• Andreas

On Nov 29, 2006, at 9:42 AM, stephane ducasse wrote:

PS: I have been working with VW recently and I really found namespaces getting in my way all the time. Also the integration of namespaces in VW is badly supported at the refactoring level and other tools. So this is often a pain.

I agree with Andreas and Stef. Working with Seaside in VW right now, I can find 3 (three!) "versions" of Date in VW (Core.Date, Squeak.Date and Seaside.Date)! It kind of sucks to have to extend Seaside.Date with date method extensions already existing for Core.Date for this local shop.

Maybe namespaces of VW helped to get seaside ported to VW at all, but I'd prefer to have an ongoing desire to unify classes, which _are_ intended to work the same.

Cheers,

Markus

I think the goals for namespaces in Squeak should be two: 1. Given 2 independently developed systems, each introducing its own meaning for a new class name, a developer should be able to make them able to live together in the same image without changing the actual code for either. I think this is the real goal of scalable independent deployment. 2. If the two systems both introduce similar concepts with the same name, system should facilitate their merging by the respective maintainers. This goal is meant to facilitate sharing code that is living (and I this is what Markus is talking about).

I think many namespace systems achieve goal 1 by having each developer invent his own namespace (possibly more than one). I think this is a bad decision in our context, because it makes it harder to achieve 2. So far we've compromised by emulating this mode using the prefix convention, but only selectively.

I think the effect of first class prefixes will be to make it more convenient to delay the design and implementation of a real solution to these goals. This may be a good or a bad thing, depending on how close we feel to having a solution.

Daniel Vainsencher

Markus Gaelli wrote:

Maybe namespaces of VW helped to get seaside ported to VW at all, but I'd prefer to have an ongoing desire to unify classes, which _are_ intended to work the same.

Cheers,

Markus

Hi!

(don't have time to respond to all - but I read all)

On Nov 29, 2006, at 2:26 PM, Daniel Vainsencher wrote:

...

1. Given 2 independently developed systems, each introducing its

own meaning for a new class name, a developer should be able to make them able to live together in the same image without changing the actual code for either. I think this is the real goal of scalable independent deployment.

Yes, that's a good part of it...

Which my solution btw supports fully. :) The only problem would arise if two developers have picked the same *namespace* name - but that is far more unlikely *and* it can easily be solved by remapping or some such mechanism when loading/filing in.

...

2. If the two systems both introduce similar concepts with the same

name, system should facilitate their merging by the respective maintainers. This goal is meant to facilitate sharing code that is living (and I this is what Markus is talking about).

Exactly. This is what I am after when I blabber about "optimistic" approaches compared to pessimistic. The idea that there is real *value* in seeing class name clashes - even if they are in different namespaces - because it would be much better if they did NOT clash.

Remember - we humans only have one bucket of names in our head. We can't keep track of 5 different "Date" classes.

It may be counterproductive to burden the namespace design with this sort of criterion; how do you assess it? The problems to solve with namespaces are the ones brought about by their absence. Is lack of namespaces the reason why people implement variations on the same idea?

Eh, no... But if you look at typical namespace solutions like for example how it works in Java-land - then they suffer from this effect. Everyone happily sits in their own little "pessimistic" sandbox and invents yet another Date, BigNum, Socket or whatever...

(Not just being glib there; the problem is that if you hold out for a namespace solution that brings peace to the Levant, it will be a long wait. And the system needs namespaces.)

No. This "attribute" is available in my solution. Unless I totally misunderstand what Daniel means.

I'd offer a different second goal: the namespace solution should give clear guidance about what things should be called.

Mmmmm, not sure I understand.

Good namespace systems don't arise from syntax, nor from being backed by clever code-manipulation tools. They also, through a mix of constraint and example, give you a really good idea about what the name of something ought to be.

That's important, because if there isn't an obvious way for development effort x to name its stuff (to some coarse level of precision) then there isn't an obvious guess I would make to find that stuff so I could use it.

Sure.

Policy that constrains the choices when you name a piece of code pays that limitation back in spades by making it easier to find everything. In good systems, resolving namespace conflicts is a local matter, about as deep, interesting, and worth attention as the onerous problem of an inherited instance variable name clash (i.e. rare and boring.)

So if you're going to pick a namespace design, it might be worth talking about what kind of naming policy you're going to use. A question to answer: in a namespace-mature squeak, what will be the fully-qualified name of Object ? SharedQueue? Monticello's Package? Croquet TFrame? Seaside internal utiltities?

Right - this is important. I would call the problem "How do we partition our classes in namespaces?".

And this is interesting. Some people mix the concept of modules with namespaces. A Module IMHO is a "separately deployable/loadable unit". It does NOT equal a Namespace.

A Namespace is a space of names in which a single human (or a group) takes on the responsibility of making sure the names in that space are unique and thus most probably are also "coordinated" in some fashion.

So... would we really need to invent fine granular spaces for the current base classes? IMHO - no. For most of what is in Squeak basic we could just use Kernel::, because that group of classes is maintained by *us*.

Object ? SharedQueue?

Kernel::Object and Kernel::SharedQueue. In almost all cases you would not see "Kernel::" in the code or ever type it because people typically make sure that their own classes don't clash with the classes in Kernel::.

Btw, note how I have started using ZZZ:: to refer to a Namespace. Kinda nice, right? That notation is typically an effect of the fact that they aren't hierarchical.

Monticello's Package?

Monticello::Package. MC is a good example because it typically has quite a bit of classes that could clash with other classes in Kernel. So either we put Monticello in the Kernel - or we use a Namespace of its own.

Croquet TFrame?

Croquet::TFrame

Seaside internal utiltities?

I would almost never have more than one Namespace for a single project. So all Seaside classes should be in Seaside:: just like today (WA*). Why? Because again - we aren't talking about "modules" - we are talking about a space of names. Why would the Seaside developers have problems with name clashes *within their own project*?

And when I come along with my new little pet project, how do I decide what to start calling my own things, and how is my claim laid to those names I use?

Use a descriptive name - typically the name of the project. We do have SqueakMap and we could easily maintain unique public namespace names there.

But we should not depend on that - we just have to have nice functionality to help us if we suddenly happen to get a namespace name clash. But again - that is easy IMHO.

Then once you've thrashed out that side of the namespace question, maybe it will be easier to look at a design, and assess where it moves you in relation to the goal.

Meanwhile, Tim R. asks,

...

Forgive me if I'm being hopelessly naive here (remember, none of my degrees are in CS ) but isn't namespaces something that has been solved before?

Of course. And I don't think it's a stretch to say that the many modern answers are convergent on most of the basic points.

Which doesn't mean that they fit Smalltalk/Squeak or are good in general.

You get local short names, and fully-qualified long names; you import a long name once to use short names a lot. There's policy that lets you know what long names you're supposed to choose. People adhere to the policy because it guarantees goal 1) by construction... policy-guided fully qualified names are always unique.

Sure, many systems work this way and I urge you to reconsider. There is a REASON for Smalltalk being different and having unique values.

A common trick is to say that you use your domain name as the basis of your names, and leave your use of the tail to your own disgression. Platform components usually have a reserved rooting that is structurally the same as all the rest. That makes it always obvious when you're using 'core' stuff, and what you have to keep track of as a dependency.

There's variance in the status of intermediates (I.e., If I have a namespace Foo.Bar.Baz, is Foo.Bar a scope in which entities live, or is it just a partial name? Can I import 'Foo', or Foo.Bar in one swoop, or is there a 'package' notion that makes the next-to-last level special?)

There are questions about the interaction of namespace scoping rules with others in the language. E.g. does a class in package X which inherits from a class in package Y, automatically have unqualified access to the inherited instance variables of the Y class? (Probably, given Smalltalk's approach to protection, but it is a question to answer.)

And then are minor local questions about syntax and implementation :-).

-brad

My biggest gripes with the systems you describe are:

- Imports generally suck as Java has more or less proven IMHO. See my other post where I describe Eclipse etc.

- Hierarchies generally suck. They make everything much more complex and most people don't understand what the parent-child relation actually *means*. Does it mean that importing xx.yy also imports all its children? Does it mean that yy sees everything in its parent? Or is it just an elaborate boring scheme to make sure namespace names are unique - which people still can break by just using xx?

Remember - in Smalltalk prefixes has more or less "solved" our issues - even though in a very crude way. They are not hierarchical.

Make sure you understand *why* you want imports and hieararchies. I urge you. :) The "feel" of Smalltalk is a fragile thing. I took great care in preserving that feel with my solution. Don't think that just copying a solution from another language will preserve that feel.

regards, Göran

Hi!

On Nov 30, 2006, at 1:13 AM, Göran Krampe wrote:

...

Eh, no... But if you look at typical namespace solutions like for example how it works in Java-land - then they suffer from this effect. Everyone happily sits in their own little "pessimistic" sandbox and invents yet another Date, BigNum, Socket or whatever...

There's a difference, I think. Many of those cases I've seen in the world are ones where people consciously chose either a) to replace or extend a system facility with their own special one to meet special needs,

Yes, but that doesn't mean that it would not benefit from merging!

or b) most commonly, are simply using the most natural name for a component of their work - which is often the most natural name for someone else's unrelated component of their work.

I agree. But if they are building a piece of software that they want others to use - typically like we do in Squeak most of the time (open source stuff) then they also need to take into account that choosing a name like Component has a price. It might in that case be better to *try* to choose something more unique or more specific.

Neither is one in which there is value in assisting in the merging of these two classes (whatever it would mean to assist that, beyond letting them coexist without any inconvenience, which they generally do.)

One of the nice things about working in a namespaced system is that you can happily choose short, simple names for the innards of your stuff, and not be penalized when other people do the same.

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.

The fact that my solution shows such pollution - makes it apparent to the developers that it indeed exists - it will hopefully keep it to an acceptable level.

This is one of the "how would it play out" concerns I have about the idea of doing away with explicit disambiguation (by some sort of import mechanism)... in practice, it means all the most likely names I'd like to use for this and that would be the ones most likely to trigger :: display.... good short names for useful internal doobers would be consumed rapidly, and I'd find myself seeing and typing far more '::' than I'd like, or going back to finding globally unique names for all such things.

-b

There is one small mechanism I added and then managed to remove somehow - but it would be easy to add again. The idea is that most of the classes in a package aren't that useful outside of it - they are "private" to the package. So if you use such common short names for "private" classes - then you could mark them as "shy". The effect would be that Squeak would not consider those classes when you type those short names elsewhere - so they would not cause the popups nor the visual expansion.

Again - this violates the idea with short names being fully disambiguous (just like local references violates that principle) - but again, something we could experiment with and might be worth it.

regards, Göran

brad fowlow wrote:

Given that, do the merits benefit allotting a syntax change (a valuable commodity) that could begin to fork the world into ::-dependent and ::-free code? 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?

Bingo. That's precisely the concern I was voicing earlier.

Cheers, - Andreas

On Nov 30, 2006, at 12:13 , Andreas Raab wrote:

brad fowlow wrote:

...

Given that, do the merits benefit allotting a syntax change (a valuable commodity) that could begin to fork the world into ::- dependent and ::-free code? 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?

Bingo. That's precisely the concern I was voicing earlier.

Is there really a scheme of namespaces that would not support fully qualified names? Given that Göran's proposal basically suggests one way of expressing FQNs, shouldn't it be easily supported by any namespace implementation?

- Bert -

Hi!

Bert Freudenberg wrote:

...

Is there really a scheme of namespaces that would not support fully qualified names? Given that Göran's proposal basically suggests one way of expressing FQNs, shouldn't it be easily supported by any namespace implementation?

There probably isn't a scheme that doesn't require some sort of qualified names. However, what the exact semantics of those qualified names is, is an entirely different question. For example, there is already a significant difference between Goran's proposal and what is currently in Tweak. Goran's proposal (as far as I understand it) is effectively saying that the result of evaluating Foo::Bar is equivalent to "Smalltalk at: #'Foo::Bar'" whereas Tweak treats it as "(Smalltalk at: #Foo) at: #Bar" (with special exceptions for classes to appear in Smalltalk to keep the tools happy). The difference? Well, how about something like

TextConstants::CR

which (in Tweak) works just the way I'd expect whereas in Goran's proposal I have no idea what the intended result is.

I actually do it "both" ways right now. :)

The code on SM does it the way you say "(Smalltalk> at: #Foo) at: #Bar" as can be seen on (#scopeVariable):

http://swiki.krampe.se/gohu/35.version?id=11

...and the code I wrote last night to get the minimal core working:

http://swiki.krampe.se/gohu/35

...does it like "Smalltalk at: #'Foo::Bar'" because then there is no Namespace instance hanging at "Smalltalk at: #Foo".

Since this is compile time stuff (no speed requirement) I prefer the two step lookup for obvious OO reasons. If we want it to work that way all the time (even with the minimal core) then we need to make the core larger (add Namespace class, make sure they get created and hooked into Smalltalk upon class creation etc - I haven't looked through how much more changes that would be).

As a sidenote I have not considered using this for anything else than globals.

And decisions about semantics like here *do* matter. For example, if one agrees that the Tweak way is The Right Thing To Do, you'll immediately notice that you get into deep trouble with Goran's "source code beautifier" since you *can't* just write the abbreviated form (CR) and writing the "full form" would imply that there is some other scope that includes CR (which there may not) and determining whether a name needs to be qualified or not suddenly needs to do a deep search of all possible pools etc. etc. etc.

If we would like to use it for non globals (such as pools, which I am not sure I would like :)) then sure, it is not clear. I never intended to. One way might be to just notice that, hey, this is not a global and just never abbreviate it.

So the semantics of the FQNs are quite significant for their usage a little bit down the road. And while it may be that Goran's proposed semantics is just the right one it is equally likely that it's just the wrong one. And we haven't even started talking about static (compile time) vs dynamic (runtime) lookup of names yet. In my understanding you can only define the semantics of FQNs properly if you know what you want to do with them.

My solution was primarily compile time focused, but since we would have Namespace instances hanging in Smalltalk (that acts like Dictionaries) it also enables "normal" runtime lookup like:

Foo at: #Bar

Cheers,

• Andreas

Just giving you my thoughts/feedback, ok? :)

regards, Göran

Hi!

On Dec 1, 2006, at 11:16 , Andreas Raab wrote:

...

Bert Freudenberg wrote:

Anyway - maybe you could explain your Tweak namespace semantics a bit more? It seems equally simple as Göran's but maybe could attract more followers? I'll copy the class comment below ...

• Bert -

[CNamespace class comment 'ar 3/27/2004 17:12']

WARNING: THIS IS UNFINISHED AS OF YET! But here's how it's supposed to work anyways:

Essentially, we don't want to screw with all of the existing tools in Squeak, so we just define that all classes are in the global namespace "Smalltalk" but that the names of the classes are really fully qualified ones. So, for example, the instance variable name 'name' of class Bar in namespace Foo will contain #'Foo::Bar' and we merely fix the lookup so that the namespace contains an entry under #Bar which is found by the compiler. This allows us to leave all of tools alone working with the name of #Foo::Bar if they aren't namespace-aware and have the tools which *are* namespace aware to use #localName or #fullName as they desire.

This scheme has various advantages: a) You can reflect about all classes in the system by enumerating through Smalltalk (useful for system-wide tools). b) When we print an object (or inspect a class or similar) we will see it's full name which is good as it avoids confusion. c) If we want to "import" some class it will know where it was defined so we can track that dependency accordingly. Etc. This seems *hugely* advantageous to approaches which try to keep the "local name" of the class and do all sorts of guessing about "who this guy is" (say, Environment>>scopeFor:from:envtAndPathIfFound:) - after all if a class doesn't know where it is defined, who the hell *would* know?

So the basic approach here is: Classes know who they are and where they are defined, and we can ask them for a local name which will be a "shorthand notation" in their namespace.

So far this seems IDENTICAL to my solution, modulo any misunderstanding on my part.

The stuff that really doesn't work right now is to fix the tools to the point that they can deal with namespaces AT ALL. There are so many freaking places in the system that are hardwired it's almost impossible to fix them all at once. For example, there's an interesting issue with respect to defining classes - those class definitions *have* to be executed by the environment that defines the class but unless we want to change the class definition message (which would screw up even more tools) you can't really guess which name is being used. Argh... anyways if you want to see what I'm talking about try to define something like:

Squeak::Object subclass: #Object instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Tweak-Kernel'

inside the Tweak namespace. You'll see what I'm talking about...

This part I need to test to understand the problem. :) I don't have a Squeak handy right now but if the intention is to create a class Tweak::Object, then why not name it that?

regards, Göran

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

Hi!

Andreas wrote:

Göran Krampe wrote:

...

Either *that* is a bug or the fact that you later *can't reference them by their name* in your code is a bug.

As the above example shows the bug is that the class name is not validated. And yes, that is quite obviously a bug (which is even somewhat funny since I did validate inst vars and class vars and pool vars and about everything I could think of in ClassBuilder - just not the class name itself)

Right. I just wanted to get people to notice that we aren't that "Squeaky clean" as we sometimes think we are. It sounded like an argument for my solution and that I take back.

...

...

...

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.

Let me repeat: Language design is not a zero-sum game. I don't care if the change is four or four hundred lines of code.

Well, in practiec I really don't think you don't care about that. :) If it was four hundred lines I am pretty sure you nor anyone else would even contemplate putting it in. :)

I don't care if VW's namespaces suck or if Croquet uses positional arguments. In *this* discussion I care about whether a change like you are proposing is worth it based *exclusively* on its own merits.

I agree with the "on its own merits" of course. The point of noticing Croquet "diversions" from regular Squeak is to get people to see that we (as in all Squeakers - forks like Croquet included) are indeed already changing things making various forks incompatible with each other.

I clearly recall this positional thing popping up in another thread when someone was trying to get something from Croquet working in regular Squeak (my memory sucks).

And if you are jealous that Croquet is able to make decisions you have a

No, I am not jealous.

simple alternative: Make up a fork that shows the error of everyone else's ways. As a matter of fact I would vastly prefer that because it would mean that there is some actual usage to look at and that I don't

The idea of forking Squeak has indeed occurred to me, but not for this reason.

have to take you at face value with all of these (so far completely unsubstantiated) claims. The nice thing about forks is that you can look at them, try them out, and then, with 20/20 hindsight can say whether a change like it makes sense for Squeak in general or not. But I don't think even you have used your namespace solution anywhere.

No, I haven't. I will though, but I don't think it will buy much more insight than possibly flushing out a few bugs and add a feature or two. It doesn't really say much about the larger picture.

So what exactly are your claims based on?

I am slightly unsure what you mean with "claims". If you mean my claims on how the code works - they are based on my own knowledge of what the heck I did. If you mean my "claims" on how it would play out in practice on a large scale it is of course pure guessing - in fact pretty much like anyone else's "claims" on how another solution would work.

If there is any other claim you refer to - please specify.

Cheers,

• Andreas

Let me just finish by saying that it was not *I* that brought this up once again, ok? Someone asked about Namespaces in Squeak and Bert pointed to my solution - and from there it went.

I am explaining and defending my solution, but I have generally given up on getting it accepted - it is just the same story all over again. So you don't have to worry. :)

I will try to document it in painful detail and will play with it myself - but as far as advocating its inclusion goes, someone else will have to step up.

regards, Göran

Hi!

Göran Krampe wrote:

...

I agree with the "on its own merits" of course. The point of noticing Croquet "diversions" from regular Squeak is to get people to see that we (as in all Squeakers - forks like Croquet included) are indeed already changing things making various forks incompatible with each other.

It is extremely irritating to see these references to Croquet, traits, pragmas etc. which have nothing whatsoever to do with your proposed solution. So maybe you should stick to the benefits of your solution instead of making references to completely unrelated projects?

Mmmm, we are using them as examples of changes to the syntax and language - which they clearly are - and which this clearly is too. There is nothing wrong in doing that. If that annoys you, too bad. ;)

...

I clearly recall this positional thing popping up in another thread when someone was trying to get something from Croquet working in regular Squeak (my memory sucks).

Yes, in the OpenGL package. Which is (not coincidentally) the sole reason why we added it to begin with. Because, if you're a 3D guy you know OpenGL. And OpenGL has a *lot* of documentation that we could leverage by making it possible to transcribe C-code from:

glBegin(GL_QUADS); glVertex3f(0.0, 0.0, 0.0); glVertex3f(1.0, 0.0, 0.0); glVertex3f(1.0, 1.0, 0.0); glVertex3f(0.0, 1.0, 0.0); glEnd();

literally into:

ogl glBegin(GLQuads); glVertex3f(0.0, 0.0, 0.0); glVertex3f(1.0, 0.0, 0.0); glVertex3f(1.0, 1.0, 0.0); glVertex3f(0.0, 1.0, 0.0); glEnd(); yourself.

In other words you can copy and paste large portions of OpenGL code literally into Croquet and I think that was completely worth it.

I probably agree and have never said it wasn't worth it.

...

...

The nice thing about forks is that you can look at them, try them out, and then, with 20/20 hindsight can say whether a change like it makes sense for Squeak in general or not. But I don't think even you have used your namespace solution anywhere.

No, I haven't. I will though, but I don't think it will buy much more insight than possibly flushing out a few bugs and add a feature or two. It doesn't really say much about the larger picture.

You may be surprised about that. Speaking from my own experience just being able to use a fundamental feature like this in your daily work changes how you look at it. Because *wherever* you go you have the option to use it and when you had that chance for a couple of months and look back and say "so why did I use it here and not there and what would need to be true for me to use it there" is *extremely* helpful for understanding your own implicit motivations and what you expect from the solution you originally designed.

Yes, might be so - ask me in a year or so.

...

If there is any other claim you refer to - please specify.

No, it's just those - does that solution actually buy you anything in the long term, how do you use it in daily work, does rewriting your source code get annoying etc.

Ok, gotcha.

...

I am explaining and defending my solution, but I have generally given up on getting it accepted - it is just the same story all over again. So you don't have to worry. :)

The funny thing is that like I said initially I don't even care all that much but for some reason you get totally defensive about these issues.

Mmmm, perhaps I do - I apologize for that. I have tried not to :).

And there are things I simply won't let slip by like factual errors about what is and what is not true in the current system. If you want to advocate your solution, go for it, just don't do it based on provenly false claims (like "you can already use colons in class names so we must support this in global references" which will make me respond every single time).

I should have written that "you can already *create* classes with colons in their class names" - which is true no matter the reason. And AFAIK I did write that it probably was a bug, right? And I did take it back as an actual *argument* - which it was not really meant to be, I was more trying to indicate that things aren't that well defined as some may think.

regards, Göran

Again what is the difference between really naive simple namespace proposed by goran and prefix usage. Seriously I do not understand. Really! I should be too stupid. On the one you cannot say look this is simple and cool and what does it brings. I mean really, deeply versus the cost (ie fixing all the places that will break). it is just that you can load and that in case of conflict you can say move this def in this namespace?

Stef

PS: what I see is that this anedoctal for now compare to all the tasks that could improve squeak: - more tests - toolBuilder usage - better packaged code - clean dependencies - removing dead code/broken code

Hi!

Hi all ...

one thing I really love in Smalltalk after programming years in different languages (and since 1996 in Java) is the simplicity and the really straight concept. One point is, that I don't have to deal with imports (or my IDE doesn't has to deal with it), I just wirte the class name and it's OK. All I need is in my image. Oh, yes, many of those classes have a little prefix of two or three chars, but who cares? That makes it allways clear, which implementation I use. So even in VisualWorks I use my TLAs as prefix, it makes live more simple.

Adding namespaces adds complexity, a litte one, but it does. Smalltalk would loose a piece of its advantage.

I agree 100%. That is very much my own feeling but I went ahead and thought "Can we still do *something* that actually maintains this feeling?" and that is how I came up with my solution.

In practice most things would just continue to feel and look like before. You can still create classes *without* prefixes. You can still use packages using the old prefixes. There are no new tools needed, and no complicated models to learn - everyone can learn that ok - if you used class names like "WAComponent" before you can now instead use "WA::Component" and you get a few nice advantages. Easy.

And there are no imports and there are no multiple contexts. IMHO it only improves on the situation that we *already* have - prefixes.

If you haven't read it:

http://swiki.krampe.se/gohu/32

regards, Göran

Forgive me if I'm being hopelessly naive here (remember, none of my degrees are in CS ) but isn't namespaces something that has been solved before? I mean, it's not exactly a new issue is it? Isn't there a standard somewhere for dealing with them?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Giraffiti (n): Vandalism spray-painted very, very high

Hi lex

Just a question. Do you think that in practice nested namespaces are needed (not in the context of Java). I have the impression that this introduces complexity.

Stef

On 30 nov. 06, at 13:06, Lex Spoon wrote:

tim Rowledge tim@rowledge.org writes:

...

Forgive me if I'm being hopelessly naive here (remember, none of my degrees are in CS ) but isn't namespaces something that has been solved before? I mean, it's not exactly a new issue is it? Isn't there a standard somewhere for dealing with them?

It is an old issue that has seen a lot of research. I don't think there is a consensus on a good solution, though. Keep in mind that this stuff is related to the ongoing work on components, an area that seems to be nowhere near mined out.

Practically, a Java-like solution seems pretty good. There is room for incremental improvement in that area, though. The generalized imports of Scala seem helpful, IMHO. As two examples of this (and attempting a Smalltalky syntax):

import Core.Date -> CDate "import Core.Date, and" "rename it to CDate in" "this scope"

import Deeply.Nested.[Package -> Pack] "make Pack be a shortened" "version of Deeply.Nested.Package"

These are small improvements over Java, but I use them all the time.

-Lex

Actually, IMHO import lists like in Java or Python do not fit Smalltalk at all. Sure, people want to use unqualified names in their code. But in those file-centric environments, you know exactly where to look to identify which local name refers to which global name - you scroll up a few pages to the import list. Also, these imports always travel with the code using them, because it's in the same file.

This confirms why I have doubts about import. But this is intriguing. don't you think that if package were first class they could be the compilation unit and get import attached to them.

Not so in Smalltalk. As has been noted elsewhere, the compilation unit is a method in a class. Consequently, you need either fully qualified names, or have class-based imports. We already have a way to express the latter (class pools [*]), and we may like to have a way for the former. That's all.

Stef

Hi Lex,

on Thu, 30 Nov 2006 13:06:54 +0100, you wrote: ...

Practically, a Java-like solution seems pretty good. There is room for incremental improvement in that area, though. The generalized imports of Scala seem helpful, IMHO. As two examples of this (and attempting a Smalltalky syntax):

import Core.Date -> CDate "import Core.Date, and" "rename it to CDate in" "this scope"

import Deeply.Nested.[Package -> Pack] "make Pack be a shortened" "version of Deeply.Nested.Package"

Interesting. Then, when you ask for all references to Package and later to Pack, what are the respective results?

Is this under the assumption that atoms in name space are unassignable objects (like: classes); what happens when Pack := nil ?

/Klaus

These are small improvements over Java, but I use them all the time.

-Lex

...

PS: I have been working with VW recently and I really found namespaces getting in my way all the time. Also the integration of namespaces in VW is badly supported at the refactoring level and other tools. So this is often a pain.

I agree with Andreas and Stef. Working with Seaside in VW right now, I can find 3 (three!) "versions" of Date in VW (Core.Date, Squeak.Date and Seaside.Date)! It kind of sucks to have to extend Seaside.Date with date method extensions already existing for Core.Date for this local shop.

Maybe namespaces of VW helped to get seaside ported to VW at all, but I'd prefer to have an ongoing desire to unify classes, which _are_ intended to work the same.

These 3 Date classes are the result of difficult design decisions.

1) Seaside uses Duration, DateAndTime, Year, Month, Week, and maybe a few other that are part of so-called Chronology. These classes are not available in VW. 2) I was lazy and rather than re-implementing Chronology in VW, I ported the Chronology package to VW. 3) Porting Chronology from Squeak to VW created name clashes for Date and Time classes. VW namespaces helped here with Core.Date and Squeak.Date, Core.Time and Squeak.Time. Note that there is no clash for Timestamp (TimeStamp in Squeak) and for Timezone (TimeZone in Squeak). 4) Now that I had two different classes for Date and two different classes for Time, I had to decide which would be used in VW Seaside. I did this by subclassing Squeak.Date and Squeak.Time as Seaside.Date and Seaside.Time. Again namespaces helped here.

I'm not that proud of the result that looks more like a hack, but it has worked fine so far and without too much work. Many Seaside add-ons like ShoreComponents, SeasideTesting, RSRSS port nicely and silently to VW thanks to the hack. A probably better solution would be to re-implement Chronology in VW (with the ongoing desire to unify...). I feel however that there might possibly be some potential semantic differences between VW and Squeak in this area that would create some different issues with some other difficult design decisions to come.

So, yes, VW namespaces helped (a lot!) to get Seaside ported to VW.

For your specific problem, rather than extending Seaside.Date with methods that exist in Core.Date, you could also change the superclass of Seaside.Date to be Core.Date. Then, you may have to extend Seaside.Date with methods that exist in Squeak.Date :-)

If some applications need Core.Date and some other need Squeak.Date, then you can try defining different namespaces and define MyNamespace.MyApp.Date and MyNamespace.MySecondApp.Date, and extend them as needed :-). That looks complicated but that would probably work.

Göran Krampe wrote:

Foo::Bar == (Smalltalk at: #'Foo::Bar')

In fact, I believe it was you Andreas that strongly suggested I should do it this way or take on a world of hurt. :)

Right, because it's the only way to make it so that the tools would continue to work (since none of them is namespace aware).

...

So basically you're trading the probability of conflicts (reduced due to the increased length in names) with the severity of conflicts (increased since changing the prefix is more expensive).

Ehm, how can it be more expensive? You mean compared to changing a single clashing class name?

Yes.

And it *does* enable experimentation with prefix hiding (as I do in the tools part) or even experimenting with explicit imports (which I detest - and even Stephane now seems to think is a bad idea - but hey, feel free to play around).

Interesting. I'm just the other way around - I detest the idea of tools rewriting source code under my feet and have code in the morning look different from the same code in the afternoon, and have code that would perfectly compile in the morning not compile in the same way in the afternoon. And, I think imports are critical for scalability - because they a) declare dependencies explicitly and b) allow the *user* of a package/global to decide under which name to use them. The Python module system works that way and it works great.

...

But since it's "only" an incremental shift in tradeoffs I wonder if a language change (with significant costs for compatibility) is really justified.

Is the "language change" really of that kind? You can already have global names with : in them (which is funny) but if you try using that for a class you will get into trouble - a bug IIRC. So the small changes could even be considered to be a bug fix. :)

Hardly so. Code that doesn't work in any previous Squeak version and doesn't work in any other dialect cannot be called a bug fix. It's a significant syntax change.

I agree that it deliberately does not involve dependencies, and only a little bit about visibility (the tool extensions I did have some visibility mechanisms) - because I think we can first add the *basic* notion of "named buckets" (=Namespace) and the *basic* syntax - without blending those two issues into the pot.

If someone then would want to tie these Namespaces into dependencies, imports, modularity etc - then that is IMHO a "next step".

Yes, and that's the major reason why I'm not violently against it ;-) It *may* be a step that needs to be taken now but I'm still wondering if we won't be stuck forever at this point because even between the two of us we can't agree on some very basic notions (imports or not). That's why I'm judging this independently of the follow-on steps (which may or may not happen) and that's why I'm wondering if changing the syntax at this point is really worthwhile.

BUT... if we intend to try to tackle those two beasts on the language level (instead of say SM or MC level), then perhaps a Namespace "notion" is a first step.

And it doesn't seem to be a dangerous step either. But it will enable experimentation.

Experimentation is already enabled by having it loadable from SqueakMap. And there are quite some risks associated with it most importantly that of inventing an esoteric construct that nobody wants and nobody needs because we may not understand the needed semantics well enough to make it work out in the long term.

To summarise - it reifies prefixes and makes them concrete and easy to manipulate, and easy to spot. That is all, and since we *have* these things already (prefixes) - then making them tangible, concrete, real objects seems like a useful thing to do.

I agree with all of that. What I'm not sure about is whether that (on its own) is reason enough for a change in syntax. The trouble with syntax is that once it's chosen and once a semantics is chosen we're essentially set with it. So are we certain, are we *absolutely* certain that we understand the semantics of that change well enough to say that "yes this is the semantics we need for the follow-on steps and it is extremely unlikely that we'll need anything but that"? I'm not.

Cheers, - Andreas

On 29 nov. 06, at 19:54, Andreas Raab wrote:

Interesting. I'm just the other way around - I detest the idea of tools rewriting source code under my feet and have code in the morning look different from the same code in the afternoon, and have code that would perfectly compile in the morning not compile in the same way in the afternoon.

:) me too.

And, I think imports are critical for scalability - because they a) declare dependencies explicitly and b) allow the *user* of a package/global to decide under which name to use them. The Python module system works that way and it works great.

Can you give an example? Do you mean that you can alias them?

I thought that imports at the package level (may be with alias) would be a nice solution, since we could have a flat view of the world inside a package or method and change the binding at the border (import statement). So I could plug a different (but compatible input) to my package. Now after thinking a lot about that I'm not sure. So I arrived to the conclusion that trying on a real system is the only way and I do not have the time for that so I'm stuck with my thoughts :)

Stef

You bring up good points, but how would you implement something like this in smalltalk? A "compilation unit" (and thus a lookup context) in python is a file. A "compilation unit" in smalltalk is a method.

From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Wed, 29 Nov 2006 20:00:26 -0800

stephane ducasse wrote:

...

...

And, I think imports are critical for scalability - because they a) declare dependencies explicitly and b) allow the *user* of a package/global to decide under which name to use them. The Python module system works that way and it works great.

Can you give an example? Do you mean that you can alias them?

No, I mean that a user can decide what's important for him and where to qualify and where not. For example, consider that both Tweak and Morphic define a class named Button. In Goran's proposal it means that you always have to qualify Button everywhere you see it; even in the innards of Morphic and Tweak where there is not the slightest chance of it meaning anything but what is reasonable in this context. In Python's module system you could (in the scope you are working in; usually a file) decide to either use only Tweak (and not qualify) or use only Morphic (and not qualify) or use Tweak qualified and Morphic unqualified, or vice versa, or use both qualified.

In either case it puts the user in control about what is important for him in the context he is working in instead of the system making requirements about qualifications of names because in some distant corner of the world a name has been used.

Cheers,

• Andreas

_________________________________________________________________ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get...

Andreas Raab andreas.raab@gmx.de writes:

J J wrote:

...

You bring up good points, but how would you implement something like this in smalltalk? A "compilation unit" (and thus a lookup context) in python is a file. A "compilation unit" in smalltalk is a method.

Sure, but this is not about a "compilation unit" it's about a scope. Such a scope can easily be defined, system categories or Monticello packages are good candidates.

It might work out well to equate all of these things. Packages, categories, and naming prefixes would be the same thing.

I do not know for sure whether this would all work out, but it seems fine on the surface. The result would be easy to think about, because programmers would not have to split hairs about, e.g., categories versus packages. It should also produce shorter code, because you could have one declaration (package foo) instead of three (package foo, namespace foo, category foo).

-Lex

From: Göran Krampe goran@krampe.se Reply-To: goran@krampe.se, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Thu, 30 Nov 2006 13:16:14 +0100 (CET)

Hi!

I agree that simplicity/unification is good in principle. One problem would be that it would "force" us to have more namespaces than we actually need. For example, I think base Squeak should just be one namespace - the "Smalltalk one" which has no prefix.

Aha. Ok, I missed this part somehow. So the Kernel::Dictionary scenario doesn't have to happen (as long as we keep it simple), but the issue is still there for other more popular packages. I guess I just see Smalltalk as it is right now as as beautiful as it can get. :)

_________________________________________________________________ Get the latest Windows Live Messenger 8.1 Beta version. Join now. http://ideas.live.com

Sorry I wasn't clear. In python (afaik) the "compilation unit" is the scope, and in smalltalk the scope is the method. I guess categories as the scope could make sense. Would you have a context menu on the category for what imports you want for this scope, or how did you envision that?

From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Wed, 29 Nov 2006 22:31:01 -0800

J J wrote:

...

You bring up good points, but how would you implement something like this in smalltalk? A "compilation unit" (and thus a lookup context) in python is a file. A "compilation unit" in smalltalk is a method.

Sure, but this is not about a "compilation unit" it's about a scope. Such a scope can easily be defined, system categories or Monticello packages are good candidates.

Cheers,

• Andreas

...

...

From: Andreas Raab andreas.raab@gmx.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Wed, 29 Nov 2006 20:00:26 -0800

stephane ducasse wrote:

...

...

And, I think imports are critical for scalability - because they a) declare dependencies explicitly and b) allow the *user* of a package/global to decide under which name to use them. The Python module system works that way and it works great.

Can you give an example? Do you mean that you can alias them?

No, I mean that a user can decide what's important for him and where to qualify and where not. For example, consider that both Tweak and Morphic define a class named Button. In Goran's proposal it means that you always have to qualify Button everywhere you see it; even in the innards of Morphic and Tweak where there is not the slightest chance of it meaning anything but what is reasonable in this context. In Python's module system you could (in the scope you are working in; usually a file) decide to either use only Tweak (and not qualify) or use only Morphic (and not qualify) or use Tweak qualified and Morphic unqualified, or vice versa, or use both qualified.

In either case it puts the user in control about what is important for him in the context he is working in instead of the system making requirements about qualifications of names because in some distant corner of the world a name has been used.

Cheers,

• Andreas

---

Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get...

_________________________________________________________________ Fixing up the home? Live Search can help http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&loca...

On 30 nov. 06, at 05:00, Andreas Raab wrote:

stephane ducasse wrote:

...

...

And, I think imports are critical for scalability - because they a) declare dependencies explicitly and b) allow the *user* of a package/global to decide under which name to use them. The Python module system works that way and it works great.

Can you give an example? Do you mean that you can alias them?

No, I mean that a user can decide what's important for him and where to qualify and where not. For example, consider that both Tweak and Morphic define a class named Button. In Goran's proposal it means that you always have to qualify Button everywhere you see it; even in the innards of Morphic and Tweak where there is not the slightest chance of it meaning anything but what is reasonable in this context. In Python's module system you could (in the scope you are working in; usually a file) decide to either use only Tweak (and not qualify) or use only Morphic (and not qualify) or use Tweak qualified and Morphic unqualified, or vice versa, or use both qualified.

Ok I see. Indeed this is close to what I was thinking. Inside your package you do not have the idea that you may have imported from different namespace. you get a flat world. And you can decide to bind your symbols in the import.

In either case it puts the user in control about what is important for him in the context he is working in instead of the system making requirements about qualifications of names because in some distant corner of the world a name has been used.

Yes

Cheers,

• Andreas

Hi G"oran,

on Thu, 30 Nov 2006 09:33:01 +0100, you wrote:

Hi!

...

There is AFAICT nothing really stopping us from putting some kind of "imports" into the system later. But it has the following "problems":

1. We loose the "single mode" that is a large part of the Smalltalk feel.

In Squeak I can type an expression anywhere and just "do it". With imports you suddenly get the inevitable question "In what context?".

This is exactly the *explicit* situation of the automated language translator and the [tendentially] *implicit* situation of the human reader / listener, thank you G"oran for bringing this up!

Nothing else than *this* *situation* needs most of our attention, when making [partially?] irreversible decisions on namespace concepts.

For quite some decades, the automating linguists have solved this problem by assigning specialized microglossaries to [arbitrary] portions of text, a (re-)usable example is:

- www.microglossary.net

A nontrivial real-world example for all the consequences (the good, the bad and the ugly), in the realm of the automated field of our discussion, with conceptually (microglossary := microtheory), is

- http://www.cyc.com/cycdoc/ref/cycl-syntax.html

...

What is the consequence? Well, in *practice* this emulates my solution - only type short names and it asks when there are choices.

And preserve that during fileOut? And cause conflicts (DNU's?) during fileIn?

You hardly ever look at the imports anymore - which is yet another evidence that you typically *know* what you use/import.

Except when you hunt for bugs where two methods of the same class (and on the same side) use different namespaces?

Ok, I hate the way imports get into my face in Java. And people are more or less only offering solutions based on very similar models. I really would like for people to try to think "out of the box" here. And I am not referring to you Andreas - you already have enough insight. But others might benefit from at least *contemplating* that namespaces:

• Don't *have* to be hierarchical.
• Don't *have* to use file/class/package level imports.

+1 - Don't *have* to be explicit.

/Klaus

regards, Göran

Hi!

Hi G"oran,

on Thu, 30 Nov 2006 09:33:01 +0100, you wrote:

...

Hi!

...

...

There is AFAICT nothing really stopping us from putting some kind of "imports" into the system later. But it has the following "problems":

1. We loose the "single mode" that is a large part of the Smalltalk

feel. In Squeak I can type an expression anywhere and just "do it". With imports you suddenly get the inevitable question "In what context?".

This is exactly the *explicit* situation of the automated language translator and the [tendentially] *implicit* situation of the human reader / listener, thank you G"oran for bringing this up!

Not sure what you mean though. :)

[SNIP of micro glossaries]

...

...

What is the consequence? Well, in *practice* this emulates my solution - only type short names and it asks when there are choices.

And preserve that during fileOut?

Yes, the fileouts (actually - the SOURCE - not just the fileout) always contain the class names. And recall the the names of the classes are the fully qualified names - just like the name of WAComponent is... #WAComponent today. No difference whatsoever with how it works today.

The only differences are in how the code viewers/editors choose to render and accept qualified names/short names.

And cause conflicts (DNU's?) during fileIn?

Nope. No conflicts, just like how WAComponent doesn't conflict with anything today unless someone uses the exact same prefix and short name.

...

You hardly ever look at the imports anymore - which is yet another evidence that you typically *know* what you use/import.

Except when you hunt for bugs where two methods of the same class (and on the same side) use different namespaces?

Waff? In Java?

...

Ok, I hate the way imports get into my face in Java. And people are more or less only offering solutions based on very similar models. I really would like for people to try to think "out of the box" here. And I am not referring to you Andreas - you already have enough insight. But others might benefit from at least *contemplating* that namespaces:

• Don't *have* to be hierarchical.
• Don't *have* to use file/class/package level imports.

+1

• Don't *have* to be explicit.

/Klaus

Unsure what you mean with "explicit".

regards, Göran

Hi!

"Michael van der Gulik" mikevdg@gmail.com wrote:

On 11/30/06, G=F6ran Krampe goran@krampe.se wrote:

But others

...

might benefit from at least *contemplating* that namespaces:

• Don't *have* to be hierarchical.

Well, this is just the next step in the evolution of namespaces. How long would it take before you go from:

Morphic::StringMorph

to

Morphic::Base::StringMorph

I don't agree. I wanted it to be a single level by design. Simple. Buckets of names. And I don't want them to be fine granular - they aren't Categories - they are Namespaces. One per Project is well enough. One for basic official Squeak is just fine - and in that particular case we just use good ole Smalltalk.

And as I wrote in some other post - what does the hierarchy really mean?

Arguably, we're not at that stage yet, and one-level Namespaces fix all our current problems. I've already been bitten by lack of Namespaces - I couldn't implement my own SocketStream because the name was already used.

Right! I did the exact same thing you know. :)

• Don't *have* to use file/class/package level imports.

Like I mentioned earlier, I need this feature for securities' sake, but I'm probably going to implement a completely different Namespace system for my own use.

Ok. So then you would be using imports purely for constraining lookup. Could easily be added of course. Btw, the core of my solution is now described in perfect detail (and I just tweaked it so that it seems to work in 3.9):

http://swiki.krampe.se/gohu/35

I'm quite impartial to how Namespaces are implemented in Squeak and I think your proposal is fine, provided that I can remove it later if it gets in my way. Currently this seems trivial, and if people don't start making unnecessary prolific use of the new Namespace syntax then I could still re-use most of the existing code.

As I said - for basic official Squeak I don't think we should use it at all. :)

So.. +1 to your proposal from me.

Nice.

regards, Göran

+1

I like Goran solution. Its true that only fixes the "prefix" problem and not the "namespace" problem, as Andreas pointed out. But to me that is not a bad thing. its one step further to make Squeak a little more comfortable.

Regards, Hernán

On 29 Nov 2006 15:59:41 +0100, Lex Spoon lex@cc.gatech.edu wrote:

Andreas Raab andreas.raab@gmx.de writes:

...

Generally speaking, I'm -1 on the proposal, mostly because what the proposal doesn't achieve is to make a real step towards enabling scalability of development (which to me is really what we're after). That's because the *author* of some code still needs to find unique names (prefixes) that do not conflict with the rest of the world and that a "change of prefix" becomes very, very expensive because it's literally like renaming all of the classes at once (and consequently breaking all of the code that uses any name from that "prefix space").

It's a good observation. Nonetheless, a hierarchical global namespace seems a good step forward over a flat global namespace. I do not know about *this* system, but in general I would love if global variables and classes had long hierarchical names. Using the existing class categories would seem great for that.

Right now, responsible programmers already fake a hierarchical namespace by putting prefixes in front of all their global names. At the very least, it would be nice to support this practice in the programming language. Ideally, you can even use long names ("Monticello") instead of short prefixes ("MC") and thus greatly reduce the chance of conflicts.

In practice, I bet it's not so hard to pick prefixes that are unique in the contexts the package will be used in. Most of the time, you can just use the name of the project, which you have surely already gone to some efforts to try and make unique. If nothing else, all the open-source projects would benefit!

Finally, keep in mind what the great naming systems you describe for the future would look like. They will probably still have path-based identifiers! The only difference from hierarchical names would likely be that the path can start from somewhere other than a single global root. Thus, a flexible hierarchical-naming system would seem like a good basis for the kind of naming system you are thinking about. (In particular, you would want Foo::Bar to really mean "Bar" within "Foo"....)

-Lex

Hi!

Howard Stearns hstearns@wisc.edu wrote:

I like Andreas' way of comparing what the proposal does to the cost of programmer changes. Determining whether his analysis is correct depends,

I agree that this is a trade off that we need to look at closely.

I think, on what the proposal is actually doing, no? I think it's possible to implement it in such a way that changes scale appropriately, but it is not yet clear to me that the code actually does things that way. -Howard

Ok, the code is small and it has class comments. If you (and or anyone else) is serious about looking at it for such an analysis I can offer a detailed writeup of EXACTLY what it does and how it works. After all, I have spent enough hours on this that I do not wish to see it all wasted. :)

Say "please do" and I will do it. :)

regards, Göran

My personal feeling on this is simply (as Step said) more research needs to be done on this. It feels like just trying to stick on a band aid. But this is less like a band aid and more like a tattoo. Once you get namespaces in, it's going to be pretty hard to take them out again if research shows a better way.

From: Howard Stearns hstearns@wisc.edu Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Wed, 29 Nov 2006 09:32:41 -0600

There's a heuristic that says incremental wins are good, but there are cases that don't apply. ("The world is better off without Saddam Hussein in power, no?") How do we know that this isn't leading the kind of "half a loaf" (non-)solution that I tend to worry about?

Guy Steele once told me that the first thing he tries to get right about a language is the namespace. "Get that wrong and you'll never recover."

I like Andreas' way of comparing what the proposal does to the cost of programmer changes. Determining whether his analysis is correct depends, I think, on what the proposal is actually doing, no? I think it's possible to implement it in such a way that changes scale appropriately, but it is not yet clear to me that the code actually does things that way. -Howard

Hernan Tylim wrote:

...

+1

I like Goran solution. Its true that only fixes the "prefix" problem and not the "namespace" problem, as Andreas pointed out. But to me that is not a bad thing. its one step further to make Squeak a little more comfortable.

Regards, Hernán

On 29 Nov 2006 15:59:41 +0100, *Lex Spoon* <lex@cc.gatech.edu mailto:lex@cc.gatech.edu> wrote:

Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>> 

writes: > Generally speaking, I'm -1 on the proposal, mostly because what the > proposal doesn't achieve is to make a real step towards enabling > scalability of development (which to me is really what we're > after). That's because the *author* of some code still needs to find > unique names (prefixes) that do not conflict with the rest of the > world and that a "change of prefix" becomes very, very expensive > because it's literally like renaming all of the classes at once (and > consequently breaking all of the code that uses any name from that > "prefix space").

It's a good observation.  Nonetheless, a hierarchical global 

namespace seems a good step forward over a flat global namespace. I do not know about *this* system, but in general I would love if global variables and classes had long hierarchical names. Using the existing class categories would seem great for that.

Right now, responsible programmers already fake a hierarchical
namespace by putting prefixes in front of all their global names.  At
the very least, it would be nice to support this practice in the
programming language.  Ideally, you can even use long names
("Monticello") instead of short prefixes ("MC") and thus greatly
reduce the chance of conflicts.

In practice, I bet it's not so hard to pick prefixes that are unique
in the contexts the package will be used in.  Most of the time, you
can just use the name of the project, which you have surely already
gone to some efforts to try and make unique.  If nothing else, all 

the open-source projects would benefit!

Finally, keep in mind what the great naming systems you describe for
the future would look like.  They will probably still have path-based
identifiers!  The only difference from hierarchical names would 

likely be that the path can start from somewhere other than a single global root. Thus, a flexible hierarchical-naming system would seem like a good basis for the kind of naming system you are thinking about. (In particular, you would want Foo::Bar to really mean "Bar" within "Foo"....)

-Lex

-- Saludos, Hernán

---

-- Howard Stearns University of Wisconsin - Madison Division of Information Technology mailto:hstearns@wisc.edu jabber:hstearns@wiscchat.wisc.edu voice:+1-608-262-3724

_________________________________________________________________ Fixing up the home? Live Search can help http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&loca...

Hi!

Bert Freudenberg bert@freudenbergs.de wrote:

On Nov 29, 2006, at 19:14 , J J wrote:

...

Once you get namespaces in, it's going to be pretty hard to take them out again if research shows a better way.

Is that so? Did you read the proposal? It does not look hard at all to back out again.

• Bert -

It would be trivial to back this out. But I guess most people arguing in this thread haven't read either the article nor have they actually looked at how it works or on the code itself. That is of course no crime, but it would be easier to discuss it if people actually looked at it. ;) ;)

But now I guess people are waiting for that walkthrough instead. :)

regards, Göran

Hi!

"J J" azreal1977@hotmail.com wrote:

Well I haven't looked at the implimentation details, no. But what will be the result is pretty obvious: Right now you have a global namespace for all classes in your image. After the change you will have the same but instead of MCDictionary or something it will be Monticello::Dictionary. In other words, the end result is just that the identifiers get longer and part of it is implicit (i.e. you don't have to type it out usually).

Yes, more or less.

The problem comes if we determine there is a much better way to do this. We can't just pull the namespaces out because then you will have 30 classes named "Dictionary" and so on. You will have to either touch them all or run some script that appends the namespace on the front of the class and then pull namespaces out. I don't see either of these as doable, so I would expect that once namespaces are in as default for a couple of years that is what we are going to have from now on.

Eh, no not really. Today without my solution MCDictionary has the name #MCDictionary. With my solution it can still be called that, or be renamed to #Monticello::Dictionary. Yes, the name of the class is the full name, not the short one.

If we then in a while decide my solution sucks... eh, I guess the only valid reason I can come up with would be that people think that 'Monticello::Dictionary' actually looks bad compared to 'MCDictionary', then sure, revert those 3 methods it is all about and remove the '::' so that it is now called 'MonticelloDictionary' - or hey, just replace 'Monticello::' with 'MC' and tada - we are back where we are now.

Renaming classes is not hard, we do it all the time. And if we ever want to move away from prefixes to anything else - whatever solution you think that we *ever* will be able to agree on ;) - then we would need to do the same anyway.

p.s. Does it get the namespace from the category? If not, then that might be something to think about. :)

The class creation template borrows the category name in some fashion IIRC. But it is only a suggestion.

regards, Göran

Hi!

...

If we then in a while decide my solution sucks... eh, I guess the only valid reason I can come up with would be that people think that 'Monticello::Dictionary' actually looks bad compared to 'MCDictionary', then sure, revert those 3 methods it is all about and remove the '::' so that it is now called 'MonticelloDictionary' - or hey, just replace 'Monticello::' with 'MC' and tada - we are back where we are now.

Renaming classes is not hard, we do it all the time. And if we ever want to move away from prefixes to anything else - whatever solution you think that we *ever* will be able to agree on ;) - then we would need to do the same anyway.

But this is my point. I think many people would use your solution because it *is* more natural to be able to just say Dictionary or SystemEditor or whatever within your package. So lets say that someone starts doing a lot of research on this in 2 or 3 years and come up with a solution 2 or 3 years after that. At that point I don't think renaming all the classes that will be using this will be trivial.

Let me just remind you that we *already* have that problem regardless if my solution gets in or not - in fact - we are even *worse* off. How come? Because we *already* use "prefixes" but unfortunately in a way that disables automated renaming. Just look: SMSqueakMap, WAComponent blablabla...

I think it will be a lot of work and thus not doable for the base image. I would just see it as a shame to not be able to adopt a new solution because of legacy.

See above.

What you said in your other message about it not coming up unless there is a conflict was good. That would make it easier to simply load other projects and not worry about conflicts, and then later fix them.

Yes, and let me here note that in my solution ALL references to globals are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in the SOURCE. Sorry for the caps, but this is VERY important to realize.

It means that I can load 34 other packages into my image and as long as we don't have *namespace name* clashes (like two people using the same name for their namespace) nothing funky will happen in my source. All references are still perfectly correct.

The only diff is that when I *browse* the code that earlier said "Dictionary" now may say "Kernel::Dictionary" because my image now also contains "Joes::Dictionar" and "Schmoes::Dictionary".

But I just don't see it working like that. I think once namespaces are in they will be used whole-sale, and the reason I think that is what you said before: we are using them now manually.

Yes, again, see above - problem *already* exists.

I hope I don't sound too negative.

No problem, I just urge you to test it or read how it works. :)

I think you have done great work and it is good to be able to load namespaces if you need them at your company.

I don't think addon namespace solutions will ever be used. I wouldn't.

For a company, a quick stop gap is very needed because you have to deliver a product in a specific time frame. But squeak isn't under such constraints, so I don't personally see a rush to put something in the image for this.

Hehe, rush? Are you aware of when I wrote this? Are you aware of how many posts I have written about it? Are you aware of how awfully many times the question of Namespaces have come up on the list? It is one of the "deadly subjects" always causing an explosion of subjective views and always end in nada.

To be clear, I think your solution is great. I just disagree with making it default in the image.

...

...

p.s. Does it get the namespace from the category? If not, then that

might

...

be something to think about. :)

The class creation template borrows the category name in some fashion IIRC. But it is only a suggestion.

Well I don't know. It sounds like you avoid a lot of the ambiguity by simply forcing every class to be explicit if there is more then one with the same name.

Note that I thought you meant in what namespace a class is *created*.

My thinking with categories was: if there is a conflict then the package could automatically resolve to the category it is in, and all classes in that category resolve the conflict to mean the class in their same category.

This mechanism of "local" references is in my solution. So yes, if a method in Foo::Bar refers to Foo::Boo it will be enough typing "Boo" and it will render as "Boo" even though you have 100 other Boos in your image. But it will be "Foo::Boo" in the actual source - as always. Because that is the name of the class.

Note that these "policy" is nicely encapsulated in a single class - just check the code. We can play with different rules for this - but I agree - "local references" is a special case in which we can "guess" for the user. If he really wants "Blooper::Boo" then he will just have to type that.

The problem with that is that there has to be a way for those classes to explicitly reference classes in other packages, and anything not in that package must always explicitly reference which class they mean. There is also the problem that some implicit magic happens with conflict resolution. So this idea would also introduce new syntax (and thus I wouldn't go for it either).

Not sure what you mean.

regards, Göran

Hi!

On Nov 30, 2006, at 12:45 AM, Göran Krampe wrote:

...

It means that I can load 34 other packages into my image and as long as we don't have *namespace name* clashes (like two people using the same name for their namespace) nothing funky will happen in my source. All references are still perfectly correct.

The only diff is that when I *browse* the code that earlier said "Dictionary" now may say "Kernel::Dictionary" because my image now also contains "Joes::Dictionar" and "Schmoes::Dictionary".

There's one thing I'm not clear on from the writeups is how legacy and namespaced code are meant to interact in this proposal, in the phase were it is being introduced. Apologies if this has been covered, its been a long thread.

You have no idea how long. :)

Sample scenario

I take a clean 3.9-ish image. I load the namespace support. I load a package that introduces the classes Someones::SharedQueue and Someones::Something <would that work, given that there is a naked SharedQueue in the system?>

Yes. You now have two classes, one named #Someones::SharedQueue and one named #SharedQueue. Just like with prefixes today.

I go into a method in Someones::Something and type SharedQueue new.

Does this prompt a disambiguation question,
and if so, how do I indicate that I want to use the system's

SharedQueue?

This is a good example. If you had written SharedQueue in Foo:: then when saving a popup menu comes up and asks which one you want. You select which one and Squeak will correct the code by inserting the prefix, if you selected Someones::SharedQueue.

But if you type it in Someones::Something then there is a policy that says that "local" references (=typing a short name that has a match in the namespace of the class that you are editing, regardless of other matches in other namespaces) are assumed to mean the local one - so it will not ask and it will not expand visually to Someones::SharedQueue - BUT the source will read "Someones::SharedQueue". Theoretically we could meet half way - not asking, but still expanding it visually - but that is not how it works today.

I can't verify this right now - but I am pretty sure this is how it works and how I meant it to work - local references is such an obvious special case that I think it is worth "deviating" from the rule that a short name always means that there are no other such short names in any of the other Namespaces in the image.

But note that this "lookup policy" for local references is actually a "Tools Issue" - we could even make that a Preference! Or you could hack in "imports" and use that. And I have isolated this policy in the code in a single class to make it easy to experiment with.

The answer earlier about how yes, one could use existing categories as defaults, but you'd do it in the class-creation template, prompted this question. What is the default full name of an existing class, when your changes are first incorporated into an image?

It depends on how we wish to partition the classes we already have, see below.

I.e. where did 'Kernel' come from in your example above, if not by automatically namespacing legacy code by category? And if that is done, does it immediately affect the content of all fileouts and package commits?

We have three choices:

1. Keep the basic classes unprefixed just as now. 2. Introduce a single space for all basic classes, like Kernel::. 3. Cut the basic classes up in several namespaces.

IMHO #3 is bad. We aren't talking about Modules nor Categories. The base classes are maintained by the same group of humans (=us) and we can make sure all their names are unique - so we should just have ONE space.

#2 was what I first envisioned - but now that you posted I recollect that someone thought it was better to just keep them in the "unprefixed Namespace" which equals Smalltalk.

So disregard my previous post and forget about Kernel:: - I recommend #1.

Or is it the case that you can't introduce a namespace-prefixed name whose base name is also present as a naked legacy class name?

If we go for #1 - that is correct since all Namespace instances are also globals. In other words - at the same instant you create Foo::Bar, the system will instantiate the class Namespace and put that in Smalltalk at: #Foo.

Sorry for the confusion.

regards, Göran

On Nov 30, 2006, at 13:59 , Bert Freudenberg wrote:

On Nov 30, 2006, at 9:45 , Göran Krampe wrote:

...

...

For a company, a quick stop gap is very needed because you have to deliver a product in a specific time frame. But squeak isn't under such constraints, so I don't personally see a rush to put something in the image for this.

Hehe, rush? Are you aware of when I wrote this? Are you aware of how many posts I have written about it? Are you aware of how awfully many times the question of Namespaces have come up on the list? It is one of the "deadly subjects" always causing an explosion of subjective views and always end in nada.

Indeed, which is why I am inclined to say "Put up, or shut up". Göran has a simple understandable implementation that people could at least try to see how it feels. Then there is Andreas' namespaces in Tweak, which are very similar to Göran's IIUC, but are not hooked up to any UI yet. Dan/Henrik had a complex implementation that people tried hard to understand or even use, so it was abandoned (although the #environment hooks are still tehre for further experiments). I don't think I saw another concrete proposal in code form.

That may sound a bit like me trying to stifle the discussion. Not at all.

Actually, I'd very much appreciate a competing proposal. Like, one that does not require a syntax change but still remains readable. Or one that does not require browser magic to transform the fully qualified names to short names. I'd just like to see any claims of superiority supported by something tangible to evaluate ;)

- Bert -

Wolfgang Eder edw@generalmagic.at writes:

Hello, I have followed the discussion and would like to chime in. What I have understood so far is that the proposal makes it possible to separate the namespace name from the class name by using a separator in the "traditional" class name.

Just to toss in my votes:

1) I am not sure that SM::Package is an improvement over SMPackage. It does not look like a large improvement, anyway.

2) A general hierarchy is an improvement over one-level. If you have a project with 1000 classes in it, then you need multiple namespaces within your project, and you want to group them under an umbrella identifier of your project. Without hieriarchical names, you will have to invent a prefix for all your namespace names....

-Lex

Hi all!

Lex Spoon lex@cc.gatech.edu wrote:

Just to toss in my votes:

1. I am not sure that SM::Package is an improvement over SMPackage.

It does not look like a large improvement, anyway.

Not sure what you mean with "improvement". Visually?

2. A general hierarchy is an improvement over one-level. If you have

a project with 1000 classes in it, then you need multiple namespaces within your project, and you want to group them under an umbrella identifier of your project. Without hieriarchical names, you will have to invent a prefix for all your namespace names....

I actually disagree. I don't think you need multiple namespaces if you have 1000 classes in the *same Project*. 1000 classes doesn't equal such a large team in practice - perhaps 10 developers? Not that hard to keep names unique IMHO. Remember that this isn't java - we don't need "namespaces" just to organize our classes - we have Categories for that.

Squeak itself is more than 1000 classes and we haven't seen any real issue in keeping the names within base Squeak unique, have we?

Finally - just because we allow Foo::Bar does not necessarily mean we want to have a "real" hierarchy and allow Foo::Boo::Bar. In fact, I would like to stay away from that and just use "buckets" - call it a one level hierarchy if you wish. Again, we have Categories for organisation - I don't see the need for having multiple levels of namespaces. And I really would like to understand exactly what semantics people think it has - it is not obvious to me as I have posted a few times now.

regards, Göran

Hi!

goran@krampe.se writes:

...

Lex Spoon lex@cc.gatech.edu wrote:

...

Just to toss in my votes:

1. I am not sure that SM::Package is an improvement over SMPackage.

It does not look like a large improvement, anyway.

Not sure what you mean with "improvement". Visually?

The onus on the proposer to say how this is an improvement. Thus far I do not see it.

I am trying my best. :) I just wondered what you meant.

I see factors in each direction that are close to a wash. Visually it is uglier, IMHO, though it is a matter of taste.

Again, you would see these colons very, very rarely:

- In the class definition, as the class name. - In methods referencing a global (=class mostly) where there are multiple namespaces defining it, AND where the method itself is NOT in one of those.

IMHO the above boils down to quite few places, especially since we also IMHO would simply use Smalltalk as the namespace for all of the "basic image".

So to reformulate the above bullet - you would only see qualified names if a method in package A references a class in non basic package B which is also defined in another non basic package using another namespace.

Regarding ambiguity, it has the advantage of decreasing ambiguity, but it pays two characters per name to accomplish this, and I am not sure it adds much in practice. In practice, the prefix is almost always all the leading capital letters except the last; the only exceptions I can think of are classes with protocols in their name (e.g., HTTPSocket).

Again, it only "pays" those colons on very few occasions IMHO. Both regarding typing and reading.

Aside from that, if you are going to spend two characters, can't you just as well add two *meaningful* characters, e.g. SqMp instead of SM? This would appear to disambiguate even further.

Of course, I don't think I was the one that introduced the SM:: example in this thread (I just kept using it) - I would typically use SqueakMap:: I think.

The tool benefits you have proposed are interesting but tricky, and are not a clear win. They are especially tricky when you consider code appears in places outside of the normal browsers. This happens all the time in Smalltalk....

If you do not do anything with the tools - then you simply see the qualified names just like you see prefixed names today - or in other words, you see some :: here and there and a bit longer prefixes. It doesn't seem like too much of a pain IMHO.

...

...

2. A general hierarchy is an improvement over one-level. If you have

a project with 1000 classes in it, then you need multiple namespaces within your project, and you want to group them under an umbrella identifier of your project. Without hieriarchical names, you will have to invent a prefix for all your namespace names....

I actually disagree. I don't think you need multiple namespaces if you have 1000 classes in the *same Project*. 1000 classes doesn't equal such a large team in practice - perhaps 10 developers? Not that hard to keep names unique IMHO. Remember that this isn't java - we don't need "namespaces" just to organize our classes - we have Categories for that.

You are agreeing we should have sub-categories, but proposing that we should accomplish this by having two different kinds of categories in the system. Isn't that a pity, though? Why not stick with one categorization scheme for names?

Ehm, we *already* have this IMHO. We have categories and we have prefixes. Sure, we could do as Todd says and give Categories a semantic meaning and skip the prefixes - but it would IMHO cause "too many" namespaces, since we then would use them for organization and not ONLY to maintain unique collections of names.

As I have said, I think only one namespace per Project/Group is enough.

We currently have a single categorization scheme. It appears practical to evolve that existing scheme into a *single* scheme for using hierarchical names to disambiguate. Given this practical strategy as an ultimate goal, it seems a pity to move in a different direction.

Well, I am not sure. I think having too fine granular namespaces is a problem. Then we are ending up like Java where they use the "namespaces" they have mainly for orgaisation causing thousands and thousand of "islands".

IMHO one of the strengths behind Categories is in fact that they ARE non semantic (disregarding PI).

Overall, it is inevitable that some of the feel Frank describes is going to get worse when we add hierarchical names of any kind. Let us try to have a clear win before we adopt something that has these definite minuses.

-Lex

Well, as I have written a few times now I don't have any high hopes for my solution getting adopted, even though people keep happily using it in "emulation mode" all the time (prefixing).

I will probably refine it and try it out a bit myself - mostly because I am interested in the feel of it - but since the resistance is so strong I have no energy "fighting" for it more than I have already done - ending this thread will be the last of it I guess.

regards, Göran

From: Göran Krampe goran@krampe.se Reply-To: goran@krampe.se, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Thu, 30 Nov 2006 09:45:56 +0100 (CET)

Hi!

Yes, and let me here note that in my solution ALL references to globals are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in the SOURCE. Sorry for the caps, but this is VERY important to realize.

I think I understand your solution pretty well. Unless I am missing something it is pretty simple: You allow :: in the class name. If it's there it is used. If the Class at the end (e.g. NS::OtherNS::Class) is unique on it's own in the system then that is all that shows up in your source. If not, then every place that is ambiguous gets explicitly written out by the compiler. Right?

I appreciate all that you have went through to do something about this, and I'm sure you have fought this battle many times.

But here is what I see personally: - The way it works today seems good enough. I know we are all prefixing our stuff, but that doesn't seem that bad. Maybe it's because I have only done smaller projects so far so I am not strong on this point, I will take the word of more experienced people (yourself included, but I'm not sure all the votes are in yet). - Suppose we use your system for the default. At first there are no classes that use it, and everything is still nice and pretty. Then one day I download some project that uses your namespaces a lot, and it happens to define Array. Now my entire image has "Kernel::Array" everywhere, right?

I don't think addon namespace solutions will ever be used. I wouldn't.

I think you mis-understand me here. I don't see the namespace problem as pressing honestly. Maybe I don't appreciate the pain this is causing because I generally prefix my classes anyway. But in a *business* you can't wait for the perfect solution. You have a dead-line that must be met. So having a drop in solution, even if it is a quick fix, is a necessity. So no, you wouldn't use an addon for personal things. Neither would I. But for my company? I have and will continue to. There just isn't time not to.

Hehe, rush? Are you aware of when I wrote this? Are you aware of how many posts I have written about it? Are you aware of how awfully many times the question of Namespaces have come up on the list? It is one of the "deadly subjects" always causing an explosion of subjective views and always end in nada.

No, I am not aware of all the history here. But none the less, this is a big issue as it changes the way Squeak smalltalk looks.

...

The problem with that is that there has to be a way for those classes

to

...

explicitly reference classes in other packages, and anything not in that package must always explicitly reference which class they mean. There

is

...

also the problem that some implicit magic happens with conflict resolution. So this idea would also introduce new syntax (and thus I wouldn't go for it either).

Not sure what you mean.

I was just discussing the problems with my first cut implementation.

_________________________________________________________________ Fixing up the home? Live Search can help http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&loca...

On Dec 1, 2006, at 8:49 , Göran Krampe wrote:

...

download some project that uses your namespaces a lot, and it happens to define Array. Now my entire image has "Kernel::Array" everywhere, right?

Well, first of all I mistakenly said in one post that the basic image would use the Kernel:: space. That was wrong (it has been a while since we discussed this before and my memory needed some kickstarting) - I instead advocate basic classes to continue being in the current global space (=no prefix).

And given that - then no, it would still say Array.

But if I have my own Array class it would then always show as My::Array, to be distinguishable from the core Array, right?

- Bert -

From: Göran Krampe goran@krampe.se Reply-To: goran@krampe.se, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Fri, 1 Dec 2006 08:49:59 +0100 (CET)

I saw in one of your earlier messages that you feel insane sometimes. I wouldn't take all this so personal. I don't think you are crazy. I think you are a great coder with a nice solution. I just disagree with putting this particular one in by default.

_________________________________________________________________ MSN Shopping has everything on your holiday list. Get expert picks by style, age, and price. Try it! http://shopping.msn.com/content/shp/?ctId=8000,ptnrid=176,ptnrdata=200601&am...

...

...

The problem comes if we determine there is a much better way to do

this. We

...

can't just pull the namespaces out because then you will have 30

classes

...

named "Dictionary" and so on. You will have to either touch them all

or run

...

some script that appends the namespace on the front of the class and

then

...

pull namespaces out. I don't see either of these as doable, so I

would

...

expect that once namespaces are in as default for a couple of years

that is

...

what we are going to have from now on.

Eh, no not really. Today without my solution MCDictionary has the name #MCDictionary.

You just said "no", and then repeated J J's post in your own words. ;)

In some sense yes. :) But I tried getting the subtle differences across - like that the name of MCDictionary is not its short name with my solution being in - it is the fully qualified name.

So there is AFAICT no difference from the current state - when we have MCDictionary.

In short: you can add hierarchical names with no immediate cost, but once people use it, it would be a much larger cost to go back.

While, I like hierarchical naming in general, there is no denying that there are plenty of issues to consider.

-Lex

I agree. And yes, there is a cost. But people seem to think that we have these choices:

1. No change at all leaving us without Namespaces as it has always been. We don't need no darn Namespaces!

2. Adding my solution now that gives us Namespaces that don't seem so impressive to all the language scientists (hey, no imports? It must suck).

3. Wait for some "stronger cool advanced" solution coming soon solving all problems known to man kind regarding naming, dependencies, modules etc.

When in fact we IMHO probably have these choices:

1. Live on with "manual" namespaces using prefixes that doesn't enable any proper tool support. We have them ALREADY - don't deny it.

2. Fix prefixes so that they can at least be used as proper Namespaces and enable tool support and what not. It is just an improvement on what we ALREADY have.

3. Wait forever for "stronger cool advanced" solutions that will be presented, shot down and never enter the official Squeak. And during this perpetual wait we will still be using crappy prefixes, while arguing to death on squeak-dev about different models more incomprehensive than the next.

Wanna bet? :)

regards, Göran

PS. To all recent Squeakers - Namespaces is a well known squeak-dev killer subject. It pops up EVERY year, creates tons of posts and never any real changes. I wrote my solution more than 2.5 years ago!!! And that sure wasn't the first time this was discussed - remember Squeak 3.3alpha?! Or Dan's environment experiment which predates even that? Don't think this is anything new, it is just a recurring cycle. Lord knows how the hell we got Traits into 3.9 - it is a bloody miracle. :)

When in fact we IMHO probably have these choices:

1. Live on with "manual" namespaces using prefixes that

doesn't enable any proper tool support. We have them ALREADY

• don't deny it.

2. Fix prefixes so that they can at least be used as proper

Namespaces and enable tool support and what not. It is just an improvement on what we ALREADY have.

3. Wait forever for "stronger cool advanced" solutions that

will be presented, shot down and never enter the official Squeak. And during this perpetual wait we will still be using crappy prefixes, while arguing to death on squeak-dev about different models more incomprehensive than the next.

Wanna bet? :)

regards, Göran

I agree these are the real choices. We already manually prefix classes to avoid clashes, and it's absurd we don't have tool support for this idiom. If Traits and Pragmas can get included, surely something as simple as Göran's proposal which only objectifies an existing idiom can be seriously considered.

I see a lot of arguments for #3, wait for a better solution... but Göran's solution is much more pragmatic, and more importantly, available. If we can't formalize existing idioms, then it's highly unlikely something more advanced would ever fly, leaving us stuck with the status quo, manual prefixing, which sucks.

PS. To all recent Squeakers - Namespaces is a well known squeak-dev killer subject. It pops up EVERY year, creates tons of posts and never any real changes. I wrote my solution more than 2.5 years ago!!! Lord knows how the hell we got Traits into 3.9 - it is a bloody miracle. :)

I'm beginning to see that. This is a serious issue that needs to be handled eventually. If Squeak is to gain a wider developer base, we need to be able to load packages without them breaking each other so easily. Smalltalk seriously rocks, but nothing is beyond improvement, and maintaining the status quo isn't always the best answer.

PS: what I see is that this anecdotal for now compare to all the tasks

that could improve squeak:

• more tests
• toolBuilder usage
• better packaged code
• clean dependencies
• removing dead code/broken code

Stef

No disrespect intended, but what is the point of this? What matters is not what "could" be done, but what "is" being done. Göran is bringing a solution to an outstanding problem to the table. Solutions are what should be given real attention, not problems. It's easy to point out problems, but very few people put a solution on the table, and apparently, he's been bringing this one up for a while.

What happened to do the simplest thing that could possibly work? Göran's solution has this quality, it's simple, it's what we already do manually anyway, and I can already create a class named SomeSpace::SomeClass, I can even already create instances of it like (Smalltalk at: #SomeSpace::SomeClass) new. The only thing I can't do is reference it directly by SomeSpace::SomeClass.

Is what he's proposing really so objectionable? Really? It seems a minor bug fix that will enable tool support for existing idioms, why wait for some unwritten ultimate solution when we could have this now? Maybe I'm just too new and missing something, but I don't understand the resistance.

Ramon Leon http://onsmalltalk.com

Hi ramon

The point that andreas raised is valid. My question is what do namespaces really bring us?

They would let me type User instead of SSUser, SPUser, KTUser, FAUser, and if multiple User classes were detected, they'd ask me which one I meant. And if one was in the current package, it could assume I meant that one and not have me think about the prefix.

(Did you ever program in VW? Just give it a try. You will come up really fast with we need more tools support. Ok in VW namespaces are not that cool but they do more.)

No, but I hear they aren't so great.

***Namespaces will not let you load a code that have the same name.*** SD::Foo is the same as SDFoo. No matter how you want to read it. So if your code contains SD::Foo already then you

That's not their intent. Their intent is to automate the prefix stuff so we don't have to do it manually. Yes, SD::Foo would clash with SD::Foo... But it won't clash with WA::Foo, ZW::Foo, or QT::Foo, which is how it helps me.

are screwed . If you use the same namespace than me we will clash. The proof is that in VW you have to ***register*** your namespace on a wiki! yes on a wiki. So we could register prefix.

Unnecessary in Goran's proposal.

So conclusion simple namespaces do not help avoid clashes.

Yes they do.

VW people tried to explain to us that yes in certain occasion doing a private import in a namespace is the right action to do. because you can reuse your code and substitute other components...... Sure may in 1.9 % of the case and this is not the problem solved by the proposal of goran!

So I'm not against a solution to a problem but what is the problem we are talking about here?

Manually prefixing classes to prevent name clashes, and being forced to use those long names when the tools could do it for us, and hide it from us in the browsers.

Having shorter Class names? because this is not about name clashes. Namespaces do not solve that....

Namespaces do solve that. They let me have a Foo class in every project without me having to manually prefix them all. To me... the name is Foo, to the compiler/fileOuts, it's the long names which don't clash (WA::Foo, ZW::Foo, QT::Foo).

Now about traits. This is simple if people (that do not try For pragmas, do you see how important they are? We could have Stef

I'm not complaining about Traits and Pragma's, they're great, I was simply pointing out that those are major changes that have recently been adopted, so why not this minor one that'd be such a great help?

Why does it sucks? Really auto completion works, this is simple. It serves its purpose.

Because I don't like Hungarian style notations, my class name should be about the class responsibility, it should have a prefix by convention just to prevent me from clashing with other similar classes. I want to read and write User, not WAUser or FFUser and Gorans proposal allows that.

But what solution really your solution solves? Really at the end of the day when I program what does it solves? What is the problem?

I'll say it again... "Manually prefixing classes to prevent name clashes, and being forced to use those long names when the tools could do it for us, and hide it from us in the browsers."

This is Smalltalk... We shouldn't be doing anything like this "manually" when the tools could so easily do it for us.

Namespaces as simple as defined by goran will not solve this problem of breaking! Do not dream.

I didn't say solve... I said "so easily". Class extensions make guaranteeing this difficult... But Gorans solution would help, for sure. Perfection is not required to make progress. Gorans solution is progress over what we have currently.

My point is that if we want to improve Squeak there are a lot of places where we can spent times: a good package dependencies mechanism that would help us building robust set of MC packages..... But I do not understand what is the problem that namespaces as designed by goran solve.

Do programmers not scratch their own itches? If this topic comes up over and over, and Goran has a solution that some of us think works... Then obviously there is a problem, because somebody bothered to spend the time to scratch it.

I think you're too concerned about what "can" and "should" be done, rather than what "is" being done. The traffic on this thread alone clearly says this is a big issue, if you don't see what Goran's solution solves, then maybe it's not an issue for "you", but it's certainly an issue for me, and for anyone coming in from another language, it's a huge issue.

I don't really care what "can" and "should" be done, those things don't actually exist, they aren't reality. Reality is working code, and working code, when proposed, should be looked at seriously, not compared to mythical non existing solutions like someones idea of "real" namespaces and then ignored on that basis.

reply simply to this question (I still do not understand why I did not stay silent) what is a the real problem solved by this solution ?

Stef

And again I'll say, it's a tiny fix that automates something that we do manually now anyway, and is a pain in the ass. I don't like prefixing my class names, it's ugly. I pump objects across web services to .Net, where my class names are nice and pretty and simple, because .Net supports namespaces, yet I'm forced to uglify them on the Squeak side because I can't name a class something simple in Squeak and feel even mildly safe about doing so.

I'd have class name clashes with other projects of "mine". It's ridiculous that I can't have three projects, each with it's own User class, without being forced to MANUALLY prefix them, and READ and WRITE those prefixes every time I touch code.

Gorans solution removes this burden, by objectifying the prefix, he can parse it off and hide it from me. When I type a method that isn't found, Squeak asks me which one I really meant; it can and should do the same thing when I type an ambiguous class name like User. It should say hey, did you mean WA::User, ZW::User, or QT::User, and then hide the prefix once compiled. This one simple thing would greatly enhance Squeak in my eyes, and I'd bet, in others eyes as well.

Gorans solution seems simple and elegant without actually changing much, or bringing in the headache that apparently VW namespaces or full blown namespaces really are.

Now, I don't have the expertise of many in this thread, I'm simply giving my admittedly naive opinion. If there are any deep technical problems or consequences to Goran's solution I'm unaware of, I'd certainly be more cautious, but like I said... I can already create and use classes with those names without his solution. His solution appears a simple bug fix to me.

Ramon Leon http://onsmalltalk.com

Hi Ramon!

I just have to say: Thank you, thank you, thank you. :)

Really. I mean it. You seem to understand my solution perfectly. Sometimes I get the feeling I am insane. :)

No problem, it seems a simple elegant solution that solves 99% of my frustrations without changing the feel of Smalltalk.

Ramon Leon http://onsmalltalk.com

Ramon Leon wrote:

...

I'm not complaining about Traits and Pragma's, they're great, I was simply pointing out that those are major changes that have recently been adopted, so why not this minor one that'd be such a great help?

Because languages are not zero-sum games.

Cheers,

• Andreas

Touché.

Ramon Leon http://onsmalltalk.com

Hi!

"J J" azreal1977@hotmail.com wrote:

...

From: "Ramon Leon" ramon.leon@allresnet.com

...

So conclusion simple namespaces do not help avoid clashes.

Yes they do.

What (I think) he is saying is: Most people are prefixing anyway (I always do), so if you get a clash then you probably tried to make another SPUser. So just putting a couple of colons between SP and User isn't going to save you in that case.

I agree - just like in Java, if I create se.blabla.booboo.Whatchamacallit and you actually create the exact same - then sure, we get a conflict because we used the same namespace - of course!

The conclusion is false - they *do* help avoid clashes, but sure they don't prevent clashes from ever being even theoretically possible. And so? If prefixing didn't actually help avoid clashes - then why do you think people use prefixes in the first place?

...

Manually prefixing classes to prevent name clashes, and being forced to use those long names when the tools could do it for us, and hide it from us in the browsers.

It isn't going to hide it from you. It will hide the prefix *so long as no other class in the system has that name*.

Or any other policy is in effect - like for example if the name is defined "locally" etc.

As soon as *one* duplication happens *all* ambiguous classes will be fully prefixed in the source code. In the entire image.

Again, modulo any "special" policies like the local policy yes. You make it sound like we would see *more* prefixes using my solution than with the current custom of prefixing. It is the other way around you know. :)

And we can't do it the way you suggest anyway (well we could but it would be even more complicated) because if the classes are fully qualified every time (they are) and the browser hides all but the actual class every time (it does not)

Not *every time* but theory suggests that they would hide them in 99% of the cases.

then how do we know from looking at someone else's code which actual class they are talking about? Seeing colons is the indicator that there are two or more classes in the image with the same base name.

You lost me. Yes, seeing Foo::Bar indicates that Bar is not unique in your image.

...

And again I'll say, it's a tiny fix that automates something that we do manually now anyway, and is a pain in the ass. I don't like prefixing my class names, it's ugly. I pump objects across web services to .Net, where my class names are nice and pretty and simple, because .Net supports namespaces, yet I'm forced to uglify them on the Squeak side because I can't name a class something simple in Squeak and feel even mildly safe about doing so.

For you it's ugly. I don't notice it at all (so far). So what is also obvious from the traffic on this thread is that some people want it and some people don't. So to me that means it should be a loadable module for those who want it. And it is.

The problem with having a Namespace solution as a loadable module is pretty obvious. Those who use it for their packages will inevitable "force it" upon their users (of their packages).

I just don't think people will use it if is not "standard".

One thing we could think about here is to make some kind of automated tool to switch between the two so that we could all be happy. If you make a package that uses namespaces and I load it from squeakmap my system could automatically turn your namespaces into prefixes and vice versa (ok, this part is hard, but we could just make it manual on package upload).

Well, it is not impossible I guess - but the complexity sounds like it would really diminish the value of this solution. Suddenly it does not sound worth it to me.

regards, Göran

Hi!

"J J" azreal1977@hotmail.com wrote:

...

From: goran@krampe.se Hi!

The conclusion is false - they *do* help avoid clashes, but sure they don't prevent clashes from ever being even theoretically possible. And so? If prefixing didn't actually help avoid clashes - then why do you think people use prefixes in the first place?

They help avoid prefixes exactly as much as prefixing does. No more, no less. What we are basically talking about is manual prefixing with a few

Of course! :) Prefixes are just as "valid" namespaces as any other namespaces solution is. They are ALL about having a named space and putting names in there. AFAIK.

letters vs. manual prefixing with (probably) a few letters plus two colons, plus the posibility to hide the prefix with the colon solution.

So the two options are almost the same except the colon solution makes the classes uglier, but there are more options about what to do with the prefixes since the tools can detect them.

This "ugliness" notion is interesting since I personally think WAComponent is uglier than Component etc.

...

You lost me. Yes, seeing Foo::Bar indicates that Bar is not unique in your image.

I was responding to the assertion that we would only ever see the short name. But the system as I understood (and you seem to be describing here again) it would show all conflicting names explicitly and the example given had lots of conflicting names. But I guess it is a moot point. Once the

I wonder what situation would give you "lots of conflicting names". AFAIK it is still pretty uncommon.

And again, even if there ARE 4 projects using say "Component" - it is not typically so that you happen to have all 4 in your image at the same time.

regards, Göran

Hi!

...

And again, even if there ARE 4 projects using say "Component" - it is not typically so that you happen to have all 4 in your image at the same time.

I'm confused here. You mean all 4 in different namespaces? Because if so, then I can give you an example. I use Pier. It pulls in Magritte and Seaside. All three have a Component class.

Sure. We do have a few of these "common words". And they would need to be shown using :: unless:

- They are used locally (as in "within Seaside" etc), which they are 90% of the time I guess, so they could be shown short.

- When you *type* them you can still type the short name and it will ask you which one you mean. And as Todd mentioned we can have the tools "remember" one of the choices until you explicitly swith to another etc.

regards, Göran

On Dec 2, 2006, at 22:32 , J J wrote:

As far as what is the best solution for namespaces, here is my personal pick:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- November/111762.html

No new syntax (I think), and it gives a lot more then just prefixes.

This sounds like it would be realizable with Squeak's #environment hooks. Are you up to implementing a prototype so we could try it?

- Bert -

On 12/4/06, J J azreal1977@hotmail.com wrote:

...

From: Bert Freudenberg bert@freudenbergs.de Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Re: Squeak and Namespaces Date: Sat, 2 Dec 2006 23:06:02 +0100 (MET)

On Dec 2, 2006, at 22:32 , J J wrote:

...

As far as what is the best solution for namespaces, here is my personal pick:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- November/111762.html

No new syntax (I think), and it gives a lot more then just prefixes.

This sounds like it would be realizable with Squeak's

#environment hooks.

...

Are you up to implementing a prototype so we could try it?

• Bert -

Unfortunately no. I have no time at all right now (new job, long hours, long train ride, new child). But it seems like that is a problem we all have.

I know on mozilla they do a bounty system to get work done. I know it has been suggested before, but who all would be willing to put up at least $20 for something that needs to be done in smalltalk? And the more jump in, the less it would cost per person. $10 from 100 people might get some work done and might be easier to get then $20 from 50 people.

...or you could save your money and wait :-). I *need* Namespaces for security in my DPON project. Eventually I'll have some code to show; I worked on it a bit in the weekend, but got pulled away by the rest of life :-(.

My design is roughly as follows. I'm still working on it, so it may change:

- "Namespace" is a class. That's always a good starting point :-). It subclasses Dictionary and can be thought of as replacing the #Smalltalk SystemDictionary.

- Each "Namespace" has a Collection of imports, which are other Namespaces or maybe wildcards(?), and a pointer to the root namespace.

So when a shared variable such as a class is referred to from code, the compiler searches that classes' namespace, then the root namespace, then the import list. I guess a full search must be done each time and the user notified if there are multiple matches for that shared variable name.

This allows nested namespaces:

root := Namespace new. root at: #Squeak put: (squeakns := Namespace new name: #Squeak). squeakns at: #Collections put: (collectionsns := Namespace new name: #Collections). collectionsns at: #OrderedCollection put: (get the #OrderedCollection class here).

so then:

myOrderedCollection := Squeak.Collections.OrderedCollection new.

I prefer the dotted notation; this is purely a subjective preference.

Alternatively, you could do:

self class namespace import: (Squeak.Collections). "Which you'd probably do with dev tools" o := OrderedCollection new.

I still can't decide whether I want to separate the import mechanism into a separate class, so that every class has a private list of namespace imports. So far I've come to the conclusion that this would be tightly coupled, 1 to 1 with Namespace so they may as well be the same class.

This allows security: There can be multiple root namespaces each with a different set of accessable classes and shared variables. It is also allows imports to other namespaces, so that an individual namespace can be granted access to a particular class or namespace which it otherwise wouldn't have access to. If there are any obvious security flaws here, please point them out to me :-).

This would require a bit of re-thinking about how the development tools are used. I'd probably make a "Namespace browser", and you'd have to open workspaces, browsers, etc from that so that the workspaces etc have access to classes and shared variables from that Namespace.

Finally, classes will no longer have access to the #Smalltalk SystemDictionary, for obvious security reasons. There are a few notes in the wiki at http://www.squeaksource.com/SecureSqueak.html. I'll put the code there when it actually does something useful.

Michael.

On 12/5/06, J J azreal1977@hotmail.com wrote:

Did you look at the Gemstone stuff that I reposted? It sounds like that system is close to your goals and it adds no new syntax (no dot syntax, no colons, just normal message sends afaik). And I think the security of it is nice as well since it looks at the user compiling the code and then makes the link at compile time. If you file out your changes and someone else files them in, it looks like that stuff would get rebuilt so the only security problem would be if you ship the byte codes directly, but I guess they probably have some solution for that.

Yes. I used that for inspiration on how to manage import lists. Effectively, you get the same behaviour, but with hierarchical namespaces as an optional extra.

Michael.

Any link for newbies like myself? :)

From: Alan Grimes agrimes@speakeasy.net Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org Subject: Namespaces; for the record Date: Tue, 05 Dec 2006 14:13:13 -0500

For the record, I think namespaces are gay. =P

They're one of the reasons C++ sucks. I now deeply regret not speaking up against traits which is now causing the obvious problems as people begin to try to use them.

The best solution to the problem is to implement something along the lines of my Sphere operating system that I came up with five years ago. Squeak used to have a large subset of Sphere functionality in the form of the class Environment. Use that and partition the system into usable chunks. -- it really is the best solution. =)

-- People say DOS is not reliable, For me it is as constant as the speed of light. People say Linux is, I have yet to see it please me for an entire day.

_________________________________________________________________ Share your latest news with your friends with the Windows Live Spaces friends module. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...