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?
I ask because it seems that, to me, it would be relatively easy to implement an intelligent namespace system in Squeak, something we all could decide on. It could even offer backwards compatibility in that, for now, all the classes in the image are just part of the default namespace, that way nothing gets broken.
Ideas? Thoughts? Maybe a pointer to a discussion where this was already hashed out? Thanks!
Regards, Aaron
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 -
Hi!
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.
Really? That would of course be very nice - but so far I haven't really experienced an overwhelming interest from people holding the rudder (for 3.9 for example). I still think it is a great simple solution though.
There is a presentation somewhere explaining it, I'm sure Göran will dig it out if nobody beats him to it.
Well, the homepage pointed at from SM has a few writeups, this is the last one:
http://swiki.krampe.se/gohu/32
regards, Göran
PS. Yes, I have a presentation in an image somewhere but it needs a "presenter" running it.
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 -
+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 -
-----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
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_reference...
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 -
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,
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 -
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
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 Wed, 29 Nov 2006 09:42:39 +0100, stephane ducasse wrote:
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.
Mind to address your requirements from the view of ClassBoxes?
/Klaus
P.S. *package* is just another word for *problem* ;-)
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
Hi!
Markus Gaelli gaelli@emergent.de wrote:
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.
It might be worth mentioning how this would work with my solution.
The idea I have talked about earlier is that "my" solution is "optimistic" in the sense that there are no imports (which can be called a "pessimistic" approach). So if you have those three Date classes in the same image and just type "Date" then Squeak asks you which one you mean and offer a menu with all three to pick from. And when you pick it, kit gets expanded to say "Code::Date" in the browser.
In the source it is always "expanded" - it is just that the code is "rendered" with short names if Squeak knows that they are unique in the image anyway.
This means that having several "clashing" short names in the image will make it apparent that they are indeed clashing - because it will "annoy" developers that they can't just type Date and be done with it. So this is a poisitive thing - it acts like a "force" to unify classes with the same name - or rename one of them.
If you use imports then each developer sits in his/her little own box and don't "notice" that they have clashing names. And thus we more easily end up with tons of Date classes. :)
regards, Göran
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
On Nov 29, 2006, at 2:26 PM, Daniel Vainsencher wrote:
- 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...
- 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).
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?
(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.)
I'd offer a different second goal: the namespace solution should give clear guidance about what things should be called.
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. 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?
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?
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.
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.
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
Hi!
(don't have time to respond to all - but I read all)
On Nov 29, 2006, at 2:26 PM, Daniel Vainsencher wrote:
- 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.
- 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
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, 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.
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.
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
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
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.
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.
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.
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) then the proposal doesn't really give me namespaces... it's namespace emulation. 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) 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?
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.
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).
-b
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
Hi!
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
Well, I of course do not claim any Truth (TM) here but:
- Syntax change: Well, it is about allowing $: in class names. Sure, in principal this is a syntactic change I guess. But we aren't talking about anything more or less.
- Regarding changing Squeak from the compatibility view (not brought up above): If we are *that* concerned then lots of other changes recently are much more earth shattering (Traits, Pragmas etc).
- If you take an old Squeak you only need to modify 3-4 methods approximately to get it to work with new ::-code. Do realize that many other components and changes in Squeak like m18n etc are much more disruptive regarding "forking the world of Squeak" when it comes to old and new Squeak. And there are also lots of changes, even on the language level, being done in other "forks" of Squeak like Croquet or Tweak. In fact, it was Andreas that "triggered" this (my solution) way back when he wanted modifications done to the Parser/Scanner to allow "scoped variables". In fact, some of these modifications are already in Croquet (if I am correct)!
- Regarding the benefits of my ::-solution, see my answer to Stephane.
- Also, we don't *have to* colonize the base code pool if we add this. As I noted I think that the '' (empty) Namespace (=Smalltalk) should be used for our current classes in the basic image.
- And finally, about "holding out for a stronger solution": - I really don't think my solution is "weak". It is different. - I really think it will be hard, hard work introducing an elaborate, hierarchical, imports-based, alias-enabled model without destroying much of the feel of Smalltalk. And TONS of people will argue against it, since it will be such a radical change. Just my guess.
Btw, I have started that walkthrough here:
http://swiki.krampe.se/gohu/35
...during that (last night) I discovered that the core does not work on its own currently (the scopeVariable method needs to work in a more simplistic way) - but it is approximately correct. :) I will fix that. The idea is of course that the core changeset is all you actually *need* so if you grab a Squeak 3.2 you file that in and tada - all new ::-code loads and works fine. And you can even write such code in 3.2 etc.
regards, Göran
PS. It feels like history is repeating itself. Within a week I will probably have given up on getting this accepted all over again and it will be dormant for another few years. I guess it all depends on the current board and on the upcoming release team leaders.
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 -
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.
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.
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.
Cheers, - Andreas
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
On Dec 1, 2006, at 11:16 , Andreas Raab wrote:
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.
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.
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.
Agreed, although the problem in your example is just that there are two competing uses of the :: qualifier. But in the case that you only have code with one semantic and syntax for FQNs, it should not be too hard to migrate to an extended semantic keeping the same syntax. It is hard or impossible to change the semantics completely, that is true.
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.
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...
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
+1. Good points.
From: brad fowlow fowlow@pacbell.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: Re: Squeak and Namespaces Date: Thu, 30 Nov 2006 02:56:22 -0800
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.
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.
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.
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) then the proposal doesn't really give me namespaces... it's namespace emulation. 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) 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?
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.
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).
-b
_________________________________________________________________ Get free, personalized commercial-free online radio with MSN Radio powered by Pandora http://radio.msn.com/?icid=T002MSN03A07001
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
Göran Krampe wrote:
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 (!).
No, you can not. You can create *symbols* with colons in it but that's something completely different. I can also create a class like here:
Object subclass: #'Some Random Class with
#!@
in it' instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Tests'
Try it, it works. Does that mean that spaces, carriage returns and binary symbols must be supported in global references?
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)
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. 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.
And if you are jealous that Croquet is able to make decisions you have a 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 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. So what exactly are your claims based on?
Cheers, - Andreas
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
Göran Krampe wrote:
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. :)
No, I'm not sure about that. Traits were a *lot* more than four hundred lines of code (and no syntax change, btw). But you're right that at the point where it comes to implementation I would care about that. Yet, my point here is that we're not discussing the implementation - we are discussing whether a change like you were proposing makes sense at all.
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?
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.
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.
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.
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. 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).
Cheers, - Andreas
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
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 09:24:38 +0100 (CET)
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.
They allow positional arguments? Why? Or are you talking about the <> stuff.
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! :)
But you are doing almost exactly what C++ does (a namespace in C++ just gets stuck on the front of the symbol). The only difference is that C++ has a bunch of complicated import statements for compile time convenience. So I wouldn't say it is such a different concept.
_________________________________________________________________ Get the latest Windows Live Messenger 8.1 Beta version. Join now. http://ideas.live.com
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 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.
Just my two cents.
mue
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
"Frank Mueller" frank@mweb.de writes:
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.
Yes, it is a very nice thing about the Smalltalk feel.
It seems that you run into problems, though, when you scale from one thousand classes simultaneously loaded, to tens of thousands, as is happening with Squeak over time. With such a large number of global names, a hierarchical naming scheme is very helpful. At the same time, working with hierarchical names is inevitably less convenient, because you have to deal with prefixes and imports all the time.
It points to an interesting goal namespace-system designers might think about: can you make a system that scales in both directions? Can you have a system with hierarchal names, out of which you can build a nice Smalltalk80-ish 1000-name subspace where you do not need prefixes and imports?
-Lex
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
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
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
On Nov 30, 2006, 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.
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.
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.
- Bert -
[*] Try this on the class side of some class:
initialize self ensureClassPool. classPool at: #Button put: SimpleButtonMorph
From now on, you can refer to SimpleButtonMorph simply by Button. To share this "import", simply put the code into a SharedPool subclass and list that in the poolDictionaries of your class.
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
Bert Freudenberg bert@freudenbergs.de writes:
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.
That does sound onerous. With an import list per method, you'd probably end up with more than half your code being import statements!
However, suppose instead that a compilation unit was a package? Most imports would then be listed at the package level instead of the method level.
Given this, you would then have two ways to find out the symbol, just as in Java-land. First, you could browse over to the definition of the package. Second--and in any scheme we devise--you could either mouse over the identifier and see what pops up, or you could use Squeak's cool "explain" feature.
-Lex
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
"Klaus D. Witzel" klaus.witzel@cobss.com writes:
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?
You mean like the alt-N tool?
That's a good question. Thinking about it, it seems to all work out. One interesting case to think about is when you click alt-N when you are looking at the main definition of Deeply.Nested.Package. If you click alt-N there, then surely the tool should also show you references to "Pack" in the above method.
Is this under the assumption that atoms in name space are unassignable objects (like: classes); what happens when Pack := nil ?
It seems to work for any global names. The Java hierarchical-names part just turns the flat namespace into a hierarchy. The Scala-ish renaming and rewriting just provides, within a limited scope, short names that are exactly equivalent to the long names.
(FWIW, I'm sure these tricks are used in other languages, too. I'm just showing where my experience comes from here!)
In general it's just like with what Goran describes where browsers show you short names, but otherwise everything in the system is processing the long names.
-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.
Hi!
Btw, if any of you haven't read my last little article on my proposal, here it is, it is short and funny :) :
http://swiki.krampe.se/gohu/32
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
I haven't either - so I will begin by replying from memory - it might be slightly incorrect. I can check later tonight.
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'.
IIRC what we did was to add as you say a new "explicitly scoped variable" in the actual parser BUT the actual lookup implementation used when that method is triggered was implemented as "what is stored under Smalltalk at: #'Foo::Bar'".
The instances of Namespace in my code behave like Dictionaries so if you have a Namespace 'Foo' then:
Foo == (Smalltalk at: #Foo) "the Namespace itself is a global"
(Foo at: #Bar) == Smalltalk at: #'Foo::Bar' "Namespace>>at: will simple look it up in Smalltalk so it is only emulating being a Dictionary"
...and of course:
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. :)
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.
It uses the same association.
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
Two "solutions" to this:
1. Let us make SM track prefixes. 2. Make it really easy to "remap" one namespace to another when loading code.
The last idea is that the system can check for such "remaps" when filing in code (or similar) and if there is one (say from SM->NewSM) it simple asks "Code uses Namespace 'SM', should I put this in SM or in the alternative NewSM?"
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").
Yes, it is literally renaming - but it still feels quite easily doable.
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?
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).
Indeed it is not a "Grand Scheme" - but I still find it to be a useful next step that enables more advanced mechanisms as we learn and go forward.
It still is *compile time binding*. It does not change the fundamental mechanism (still uses the Smalltalk system dict) but it *does* introduce the concept Namespace (and class) and "reifies" them as globals.
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).
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. :)
And new code will work fine in an old Squeak - as long as you add those trivial tweaks (2-3 method changes IIRC) needed to have global names with :: in them.
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?
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".
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).
I more or less agree. :-o Class collisions is NOT a large problem in Squeak - dependencies and modularity on the other hand ARE increasingly so.
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.
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.
Cheers,
- Andreas
regards, Göran
PS. I had more or less given up on ever seeing the code in official Squeak, since there always seem to be people against it. I was happily surprised by Bert's post, but I don't expect nor dare to hope :) that it ever will enter Squeak. But I still think it is a good, neat step and if "the people in charge" decide that we will include it I gladly whip the code some more. It is very small btw, feel free to look and read class comments.
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
For me the key question is what do we ***really gain *** vs the cost? What is the difference between each of us systematically using a prefix? Really I do not see. Because to avoid conflict SD:: should be reserved to me exactly as before. Ok cool we will have a tool that will not show SD::. Do we want the complexity of having nested namespace/import.../
I'm not sure. Now do we want to have import per package and a scope per package. I do not know.
I think that simplicity is nice. When VW introduced namespaces we talked a lot and thought a lot of what they would bring. I'm still really perplex by the introduced complexity vs the gain.
The key questions I'm trying to understand after all these years looking at module system/namespaces/... is how do they help in achieving scalability. Do we need selector namespace? Also where do we put import is crucial: do we want to have more Unit like parametrized modules by having a bind outside the module or is the import declared inside the using package?
I discussed once with the schemers and they told me that in fact they had problems with their model and they had to modify it (but never publish the problems they got). They discovered that but only by building complex app and having to change them.
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
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
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...
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...
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
Hi!
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
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.
So if we equal namespace to either package or category that would instead create tons of them.
IMHO we have four concepts here that are different even though they may seem similar:
- Categories. This is a pure organisational unit so that we can find stuff more easily. Sure, PI today "uses" them to create Packages, but that is just a trick, albeit a nice one since it creates a mapping between categories and packages which is actually pretty nice.
- Packages. Manifested as PIs and used practically as MC packages. This is a "developer unit" IMHO.
- Namespace. As I said I think it is about a group of humans maintaining a space of unique names. An example is a project like Seaside operating much on its own with a group of developers. Another example is official basic Squeak.
- Module. The best definition of a module that I can recall was the one saying that it is a "separately deployable unit". It is about deployment. We don't have this today IMHO. Package (above) comes closest with its MC's, but it is still more of a developer construct instead of a distribution construct.
So would we want one or more of these to unite/overlap? I can't say I do actually, but would easily like to be convinced otherwise. :) Possibly Categories could be removed of course, they fill the least function and Packages more or less fits the bill there.
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 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
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 FREE company branded e-mail accounts and business Web site from Microsoft Office Live http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
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 Thu, 30 Nov 2006 07:13:49 +0100, 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.
And nothing makes {firstMethod. secondMethod} a compilation unit (except perhaps collective behavior, Adrian :)
Good point, J J.
/Klaus
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!
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
If there is another Button *in the image* - yes. But see below.
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
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?". Anyone having used VA for Java and its "Scrapbook" recalls that sure, it was almost like a Workspace - but you had to tell VA in which class it was supposed to "run" so that VA could figure out the imports. I think this effect is one of the largest "pains" when using a namespace solution with imports - and I would guess that the pains people refer to in VW might have something to do with this.
2. If you have used Eclipse and discovered alt-shift-o (or whatever key combo it is that "auto fixes" the imports) would agree with the following observation:
After having discovered this you can essentially work like this: - Type only "short names" of classes. - Regularly press alt-shift-o and let Eclipse "fix the imports". It will ask you if there are more than one match - just like in my solution.
The idea to even have a background thread pressing the key combo for you every 10 seconds has occurred - since you end up pressing it that often yourself. :)
What is the consequence? Well, in *practice* this emulates my solution - only type short names and it asks when there are choices. You hardly ever look at the imports anymore - which is yet another evidence that you typically *know* what you use/import.
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.
regards, Göran
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":
- 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
Klaus D. Witzel wrote:
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?
As I understand it, the explicit fully qualified name is maintained in the code and filed out. [ The tools *may* display them as short names if they are non-ambiguous. ]
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?
They would be fully qualified in the code, so there would not be a conflict. [ However, if you like, the tools can *display* only the short names, where these are non-ambiguous. ]
- Don't *have* to be hierarchical.
- Don't *have* to use file/class/package level imports.
+1
- Don't *have* to be explicit.
Yes, this is in Goran's proposal. [ Again, they are explicit in the actual code, but the tools *may* display the non-explicit short names if they are non-ambiguous. Similarly, you only need to enter a short name if it is non-ambiguous, if there are two or more possibilities, the tool will ask which you mean. However, the explicit name is stored in the actual code. ]
David
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":
- 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
On 11/30/06, Göran 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
or
Squeak::Morphic::StringMorph Croquet::Morphic::StringMorph Tweak::MorphicCompatibility::StringMorph
or even
Squeak::Base::Graphics::Morphic::BasicMorphs::Text::StringMorph (as opposed to any of the other 114 StringMorphs in a distributed Squeak environment...)
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.
- 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.
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.
So.. +1 to your proposal from me.
Michael.
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
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
+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
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
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
Looks like http://swiki.krampe.se/gohu/32 is the place for interested parties to start. I'll put it on my list...
-H
goran@krampe.se wrote:
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
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).
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.
p.s. Does it get the namespace from the category? If not, then that might be something to think about. :)
From: goran@krampe.se 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 19:23:10 +0200
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
_________________________________________________________________ Get the latest Windows Live Messenger 8.1 Beta version. Join now. http://ideas.live.com
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
From: goran@krampe.se 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: Thu, 30 Nov 2006 00:13:51 +0200
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.
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. 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.
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. 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.
I hope I don't sound too negative. I think you have done great work and it is good to be able to load namespaces if you need them at your company. 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.
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.
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. 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).
_________________________________________________________________ Get free, personalized commercial-free online radio with MSN Radio powered by Pandora http://radio.msn.com/?icid=T002MSN03A07001
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
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.
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?>
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?
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?
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?
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?
-b
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 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.
- Bert -
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 -
Bert Freudenberg wrote:
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 -
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.
How about having a class method that tells me what the prefix of the class name is? It could do so by guessing, or I can explicitly specify the prefix if I like to do so, by implementing the method myself. Of course it has to be consistent with the "traditional" class name, i.e. the class name must really start with the prefix return by this method.
Thanks, Wolfgang
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
Just to toss in my votes:
- I am not sure that SM::Package is an improvement over SMPackage.
It does not look like a large improvement, anyway. -Lex
It's not a large difference, but it makes all the difference in the world to automated tools supporting the hiding of prefixes.
Ramon Leon http://onsmalltalk.com
Hi all!
Lex Spoon lex@cc.gatech.edu wrote:
Just to toss in my votes:
- 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?
- 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
goran@krampe.se writes:
Lex Spoon lex@cc.gatech.edu wrote:
Just to toss in my votes:
- 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 see factors in each direction that are close to a wash. Visually it is uglier, IMHO, though it is a matter of taste. 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). 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.
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....
- 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?
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.
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
Hi!
goran@krampe.se writes:
Lex Spoon lex@cc.gatech.edu wrote:
Just to toss in my votes:
- 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.
- 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
On 12/1/06, Bert Freudenberg bert@freudenbergs.de 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.
Is that Henrik Gedenryd from Squeak 3.3?
From Google:
*I copied this important information on a new swiki page with the title *>* 'Name spaces': *>* *>* http://minnow.cc.gatech.edu/squeak/2221 *>* *>* This page can be accessed from *>* 'Modules: Design Principles' *>* http://minnow.cc.gatech.edu/squeak/2044 *>* *>* which in turn is accessed from the 'Modules' page *>* *>* http://minnow.cc.gatech.edu/squeak/2042*
http://minnow.cc.gatech.edu/squeak/734
http://minnow.cc.gatech.edu/squeak/727
And here's the start of the 2004 Namespace thread :-) http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-April/076817.htm...
Is there a document about Andrea's implementation on the web somewhere?
Michael.
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...
Hi!
From: Göran Krampe goran@krampe.se 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
No - I don't allow nested spaces. Only one level.
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?
Yes - but note that the SOURCE always contains the full name. Only the *rendering* of that source in the browser decides whether to show the prefixes or not.
I hooked into a low level spot for that and I think it works in all browsers except the method version browser - need a special fix for that one.
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).
The funny thing is that people say that "how it works today seems good enough" - in theory that sounds like a vote FOR my solution, not against it. :) IMHO my solution is just an improvement on the current ad hoc pattern.
- 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
If you consider class names like WAComponent and SMAccount nice and pretty - yes.
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.
And also - even if we did introduce spaces for the basic classes - it is still up to us/you to define the rules for space hiding/viewing.
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.
Most of us don't - I wasn't the one bringing it up this time. I just stepped up explaining it since my solution was brought forward on the list.
Also - the solution would enable stuff that we don't know if we are missing or not.
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.
Sure.
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.
Of course, just don't say that we (the proponents of my solution) are rushing anything. On the contrary.
In fact - I don't have any high hopes for my code ever entering the base image. I continue to present it and tweak it but as long as we don't have interest from the board (Bert voicing his support though was great and hey, who knows) or from the current release team leader (whoever that will be for 3.10) I don't think it will ever be adopted.
regards, Göran
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 -
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?
Yes, well, depending again on your policy. If you play with it, it would today probably show up as "Array" IF it is a reference from a method in a class in My:: (a so called "local" reference). But again, this is just policy.
For example, we might want My::Bar to show as "Bar" in code living in My::, even if we have Foo::Bar in the system - BUT... if there is a Bar in the system (a regular global - like Array) then we might want to show the full name My::Bar *even* if it is a local reference - to make it very clear that this is indeed not the regular Bar.
So in which situations we would like to only show the abbreviated name - even when there are other such in the system - can be discussed at great length - but it is just "policy".
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: 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 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
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. :)
Hi G"oran,
on Thu, 30 Nov 2006 13:04:00 +0100, you wrote: ...
When in fact we IMHO probably have these choices:
...
- 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? :)
You have at least 1.99 supporters, already (counting you full ;-). And there came other +1's.
My concern is just 1 (in words: one) message send in distance away from your implementation, even if sombody'd replace #>~ by #:: :)
/Klaus
regards, Göran
When in fact we IMHO probably have these choices:
- Live on with "manual" namespaces using prefixes that
doesn't enable any proper tool support. We have them ALREADY
- don't deny it.
- 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.
- 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? (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.)
***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 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.
So conclusion simple namespaces do not help avoid clashes. 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? Having shorter Class names? because this is not about name clashes. Namespaces do not solve that.... Or you have to introduce visibility and visibility means that you need in some way the possibility to hide or show/import/ so you cannot have the butter and the money for the butter. Either you get the full power (I understand that for mickael he needs a scoping mecanism) or you get just the trouble of having first class namespace with tools showing you shorter names and you break the syntax. Now if we want to have import....this is not clear what is the best solution (at the package level? because it could make sense). This way the package would be more an container entity for shipping code.
Now about traits. This is simple if people (that do not try them) to not want them they can be removed and we will let the Perl, fortress, VW people having (and ruby with mixin) and enjoying them. Seriously my ego does not care. Telling that traits are in Perl-6 or Fortress is more important for my CV! And this is sadly true! Now I was sad that Alan Kay was mentioning in his Turing award presentation that traits were cool and that we did not have them in Squeak. As researchers this was an EFFORT to work on traits for squeak. We gained really nearly nothing because traits are old we cannot publish on them. We did that to give a chance to squeaker to try them.
For pragmas, do you see how important they are? We could have magritte without class side methods. We can have menus, tweak behavior....I think that they are really cool and I liked them a lot and I think that this was extremely smart from VW people to introduce them because they fit really well in Smalltalk. You see I can really have problem with VW namespace and really love their pragmas!
Stef
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.
Why does it sucks? Really auto completion works, this is simple. It serves its purpose.
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. :)
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'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.
Namespaces as simple as defined by goran will not solve this problem of breaking! Do not dream.
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?
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.
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.
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 ?
note here that I do not take into account the problem mickael van gulik faces because the solution of goran does not help there.
Stef
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. :)
Btw, please read and try the "core" I just prepared (currently only tested in 3.9):
http://swiki.krampe.se/gohu/35
This is the MINIMAL change we need to add to older Squeaks so that they can deal with ::-code AFAIK. Needs to be tested a lot of course. :)
regards, Göran
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
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
From: "Ramon Leon" ramon.leon@allresnet.com Reply-To: 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 15:03:18 -0700
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.
Ok.
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.
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*. As soon as *one* duplication happens *all* ambiguous classes will be fully prefixed in the source code. In the entire image.
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) 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.
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.
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).
_________________________________________________________________ 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...
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
From: goran@krampe.se 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 10:22:22 +0200
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 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.
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 tools know it there are more options (e.g. if I am in a certain namespace hide all references to that namespace, just show references outside of it for conflicting classes).
_________________________________________________________________ Get FREE company branded e-mail accounts and business Web site from Microsoft Office Live http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
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
From: goran@krampe.se 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:14:23 +0200
This "ugliness" notion is interesting since I personally think WAComponent is uglier than Component etc.
I find WAComponent and Component about the same, but WA::Component I find unappealing.
I wonder what situation would give you "lots of conflicting names". AFAIK it is still pretty uncommon.
But in the solution I was responding to there were about 5 classes called "User".
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.
_________________________________________________________________ Fixing up the home? Live Search can help http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&loca...
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
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....
No new syntax (I think), and it gives a lot more then just prefixes.
_________________________________________________________________ Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
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 -
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.
I know there has been concerns voiced about what happens if the code isn't accepted, etc., but other groups do it. Lets just try it and see how it goes.
_________________________________________________________________ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get...
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.
From: "Michael van der Gulik" mikevdg@gmail.com Reply-To: The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "The general-purpose Squeak developers list"squeak-dev@lists.squeakfoundation.org Subject: Re: Smalltalk bounty (Re: Squeak and Namespaces) Date: Mon, 4 Dec 2006 11:03:40 +1300
...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 :-(.
I was thinking of more then just namespaces. I was thinking I would throw the question out there, and if enough people said they would donate then we could make a list of what are the biggest priorities that squeak needs and none of us are going to do in the foreseeable future.
My design is roughly as follows. I'm still working on it, so it may change:
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.
_________________________________________________________________ Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
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.
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. =)
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...
I believe that it would be Alan's own invention?
http://users.erols.com/alangrimes/UCE/
Alan: could you point me to the bit in that rather large design document that is relevant to Namespaces?
Michael.
On 12/6/06, J J azreal1977@hotmail.com wrote:
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. =)
This is pretty good.
FWIW, I am totally against adding new prefixes. All classes already have an identifier that resolves them to a "package" and that is category. So the long name of Object is really Kernel- Objects:Object. Using the one class dictionary per package strategy mentioned, I think the compiler should simply prompt the user with a menu like:
Ambiguous reference to class "Widget" Foo:Widget Bar:Widget.
It should remember this first time and resolve it that way from now on much the way it spots new message selectors and remembers that you do indeed mean that name. For the rare instance when one needs to reference two classes with the same name in different packages, one can type the optional package prefix.
That would solve the problem nicely from a user's perspective. How to make this work is left as an exercise for the implementer. :-)
-Todd Blanchard
On Dec 2, 2006, at 1:32 PM, 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.
Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/ direct/01/?href=http://spaces.live.com/spacesapi.aspx? wx_action=create&wx_url=/friends.aspx&mk
Hi!
This is pretty good.
My recollection of working with the GemStone setup was that it easily got "confusing" - BUT... that was *not primarily* because of the setup itself - but for the reason that GemStone is a multiuser environment.
In fact - if you read that post *closely* you will actually come to the conclusion that it works very, VERY similarly to my proposal - if you exclude the "multi user" aspect of it and change the lookup procedure.
It says that you have multiple "spaces" and that the space itself is in "itself" as a key. My proposal says that each space is in Smalltalk (the global space) as a key - GemStone instead has a list of spaces that it looks through one at a time.
GemStone thus has shadowing - the spaces are like layers on top of each other - a space early in the array can shadow a space later. Good? IMHO it would just get confusing and error prone *in the context of Squeak* . I simply don't see the need for shadowing like this - others may disagree - read on for an interesting side effect.
But if we disregard the above difference in lookup, they are similar:
- Both are non nested. Only one level of spaces. - Both have the spaces themselves reachable by name. - Both are compile time bound, but allows explicit runtime binding by sending messages to the "space" itself.
The example show for the latter was:
myTest := (SUnit at: #'TestCase') new.
And that code would look exactly the same in my proposal. Then James stresses that this solution hsa no syntax change - but why exactly is that a plus?
I would much rather see:
myTest := SUnit::TestCase new.
...or as it would be in 90% of the case:
myTest := TestCase new.
...than the above - when doing an explicit instantiation.
One IMHO *very* important difference with the GemStone solution is that GemStone code can bind differently when recompiled!! In my proposal all references are fully qualified in the source so they will always bind to a specific key in a specific named space. The only way to get a different result is if you have changed the value of the key - or indeed has put some other namespace at the same name (highly unlikely).
In GemStone, if you file in a package after filing in SUnit that accidentally defines #TestCase (it gets shadowed) and you later *recompile SUnit* - then it will suddenly bind to the new TestCase. Eh, oops.
As I said, I consider this to be a problem more than a feature. Having such a dynamic resolution, and NOT having imports - that seems like the worst kind of combo. ;)
Recall that GemStone is a multi user env and does not have a very active public community like Squeak has (with many public packages available). I think they are hardly comparable when it comes to use cases.
FWIW, I am totally against adding new prefixes. All classes already have an identifier that resolves them to a "package" and that is category. So the long name of Object is really Kernel- Objects:Object.
Note that suddenly giving Category a semantic meaning is a rather large backwards incompatible change. I am not saying bad or good - but it is a rather pervasive change. And I don't think they serve the same purpose.
I do propose the first part (The PI part) of the category name as the namespace name in the class creation template though - as they would probably match say 70% of the time. Mmmm, disregarding the PIs of the base image - we should probable have them on an ignore-list so that all base classes always end up by default in the global space.
Using the one class dictionary per package strategy mentioned, I think the compiler should simply prompt the user with a menu like:
Ambiguous reference to class "Widget" Foo:Widget Bar:Widget.
Which btw my proposal does. :)
It should remember this first time and resolve it that way from now on much the way it spots new message selectors and remembers that you do indeed mean that name.
That we could easily add to my proposal - a Preference or whatever. It has been discussed. Currently it has no memory and will ask each time, the only "feature" it has is that it will not ask if there is a "local" match. Again, all this is tool policy stuff - we can do it differently for every tool and every user, and top it off with 20 Preferences. :)
For the rare instance when one needs to reference two classes with the same name in different packages, one can type the optional package prefix.
Same in my proposal.
That would solve the problem nicely from a user's perspective. How to make this work is left as an exercise for the implementer. :-)
IMHO this is how it works in my proposal. I think I have already done the exercise. :) :)
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: Mon, 4 Dec 2006 09:45:42 +0100 (CET)
In fact - if you read that post *closely* you will actually come to the conclusion that it works very, VERY similarly to my proposal - if you exclude the "multi user" aspect of it and change the lookup procedure.
Honestly, I wasn't as interested in the multi-user part. That would be a nice add on, but the rest of it would possibly make nice namespaces.
And yes, the two do have some things in common. But the difference is: 1) Your solution introduces new syntax 2) Your solution doesn't really add namespaces, just prefixes in a way that lends to parsing.
With your set up, every class that is in a namespace has to have some ugly colon syntax. And we have a lot of prefixes now, so it is pretty reasonable to expect lots of ugly colons to look at after the change. And if I want to know how many classes are in a namespace? You have to scan the whole global dictionary, no? A gemstone style solution you could ask the namespace what it has in it and it would know.
It says that you have multiple "spaces" and that the space itself is in "itself" as a key. My proposal says that each space is in Smalltalk (the global space) as a key - GemStone instead has a list of spaces that it looks through one at a time.
At compile time. And when you compile one method at a time you have more time to do things.
GemStone thus has shadowing - the spaces are like layers on top of each other - a space early in the array can shadow a space later. Good? IMHO it would just get confusing and error prone *in the context of Squeak* . I simply don't see the need for shadowing like this - others may disagree - read on for an interesting side effect.
Yea, I think we could live without this part in the base.
I would much rather see:
myTest := SUnit::TestCase new.
...or as it would be in 90% of the case:
myTest := TestCase new.
...than the above - when doing an explicit instantiation.
Well in both cases, implicit instantiation looks like:
myTest := TestCase new.
In the explicit case they look like:
myTest := (SUnit at: #TestCase) new. "Gemstone style (I think thats right)" myTest := SUnit::TestCase new. "Yours"
For me sticking with the smalltalk looking syntax looks better. I know people are pretty divided on this one (not sure who is the majority).
One IMHO *very* important difference with the GemStone solution is that GemStone code can bind differently when recompiled!! In my proposal all references are fully qualified in the source so they will always bind to a specific key in a specific named space. The only way to get a different result is if you have changed the value of the key - or indeed has put some other namespace at the same name (highly unlikely).
In the multi-user case you would *want* it too, since different people have different rights. But I'm good with leaving all that out of the base and make it downloadable.
And I am with you on not making namespaces so granular. Sometimes, even with python, if the problem is small enough most of the code is import statements. One of the things I like about smalltalk is that it isn't like that.
_________________________________________________________________ Visit MSN Holiday Challenge for your chance to win up to $50,000 in Holiday cash! http://www.msnholidaychallenge.com/default.aspx?ocid=tagline&locale=en-u...
Hi!
(just posting to make sure we understand the nuances here)
"J J" azreal1977@hotmail.com wrote:
From: Göran Krampe goran@krampe.se In fact - if you read that post *closely* you will actually come to the conclusion that it works very, VERY similarly to my proposal - if you exclude the "multi user" aspect of it and change the lookup procedure.
Honestly, I wasn't as interested in the multi-user part. That would be a nice add on, but the rest of it would possibly make nice namespaces.
And yes, the two do have some things in common. But the difference is:
- Your solution introduces new syntax
- Your solution doesn't really add namespaces, just prefixes in a way that
lends to parsing.
Eh, IMHO they are just as much "namespaces" as any other kind. And moving to a multiple-dicts internal implementation - which I btw considered - is much, much harder. In fact, Andreas told me to just don't go there - it is a world of hurt.
With your set up, every class that is in a namespace has to have some ugly colon syntax.
But as I have said many times now - only visible very seldomly.
And we have a lot of prefixes now, so it is pretty reasonable to expect lots of ugly colons to look at after the change. And if I want to
I disagree, I would say it is pretty reasonable to not expect lots of them. But this I intend to demonstrate in fact, so we will see.
know how many classes are in a namespace? You have to scan the whole global dictionary, no?
Yes, but it still is pretty quick you know - about 6 ms on my box (just a quick test asking a Namespace for its keys). And as you yourself note - all these things are typically compile time.
A gemstone style solution you could ask the namespace what it has in it and it would know.
Sure, you can do the same thing with Namespace in my proposal - it mimics a Dictionary. Here are some "print its" - I have a class Fooo::Bar in the system (thus I also have an instance of Namespace sitting in Smalltalk at: #Fooo) and then I can alt-p some expressions:
Fooo keys --> a Set(#Bar) "acts just like a Dictionary"
Fooo at: #Bar --> Fooo::Bar "dynamic lookup, just like in GemStone"
Namespace newNamed: #Boo. "create a new Namespace manually, this is done for you if you create a Boo::Blabla class"
Boo addClass: Fooo::Bar "add the existing Fooo::Bar class to the Boo Namespace, it will obviously be remove from Fooo:: then"
Fooo keys --> a Set() "yup, gone"
Boo keys --> a Set(#Bar) "and there it is"
Boo::Bar name --> #Boo::Bar "this last one is hard to show in an email, but I wrote "Bar name" and pressed alt-p, it then autoexpanded Bar to Boo::Bar (in place in the workspace) and printed #Boo::Bar. In a browser this would not be visible, since it suppresses the Boo:: - but currently the Workspaces do not do that, which is nice when debugging this."
It says that you have multiple "spaces" and that the space itself is in "itself" as a key. My proposal says that each space is in Smalltalk (the global space) as a key - GemStone instead has a list of spaces that it looks through one at a time.
At compile time. And when you compile one method at a time you have more time to do things.
Yes, I was only making clear the difference. Performance is uninteresting IMHO.
GemStone thus has shadowing - the spaces are like layers on top of each other - a space early in the array can shadow a space later. Good? IMHO it would just get confusing and error prone *in the context of Squeak* . I simply don't see the need for shadowing like this - others may disagree - read on for an interesting side effect.
Yea, I think we could live without this part in the base.
Eh, but that is an INTEGRAL part of the GemStone setup. That is the whole idea with having a LIST in the first place. If you don't want shadowing then you land on my proposal. :)
I would much rather see:
myTest := SUnit::TestCase new.
...or as it would be in 90% of the case:
myTest := TestCase new.
...than the above - when doing an explicit instantiation.
Well in both cases, implicit instantiation looks like:
myTest := TestCase new.
Well, my proposal does not have "implicit" instantiation in the sense I was after - as in "what this will resolve to depends on what you have filed in since the last time".
In the explicit case they look like:
myTest := (SUnit at: #TestCase) new. "Gemstone style (I think thats right)" myTest := SUnit::TestCase new. "Yours"
For me sticking with the smalltalk looking syntax looks better. I know people are pretty divided on this one (not sure who is the majority).
Comparing those two I am definitely in favor of :: - but note that the Gemstone style works too - but then it is a runtime lookup and not a compile time lookup - which is pretty intuitive IMHO.
One IMHO *very* important difference with the GemStone solution is that GemStone code can bind differently when recompiled!! In my proposal all references are fully qualified in the source so they will always bind to a specific key in a specific named space. The only way to get a different result is if you have changed the value of the key - or indeed has put some other namespace at the same name (highly unlikely).
In the multi-user case you would *want* it too, since different people have different rights.
I have worked quite a bit with GemStone and *I* would definitely never want that and I don't think I am alone.
But I'm good with leaving all that out of the base and make it downloadable.
And I am with you on not making namespaces so granular. Sometimes, even with python, if the problem is small enough most of the code is import statements. One of the things I like about smalltalk is that it isn't like that.
regards, Göran
goran@krampe.se wrote:
Eh, IMHO they are just as much "namespaces" as any other kind. And moving to a multiple-dicts internal implementation - which I btw considered - is much, much harder. In fact, Andreas told me to just don't go there - it is a world of hurt.
Well, I don't think that is *quite* what I said (unless you have a quote to back it up ;-) but generally, yes, complex means of searching nested namespaces can get problematic very quickly. If anything, that was one of the lessons I took away from the 3.3 modules where effectively everything always included everything else and wanting to "not-include" anything became an outright adventure. But I do think there are a few ways to make that search mechanism explicit and clear (for example, by avoiding transitive import chains).
With your set up, every class that is in a namespace has to have some ugly colon syntax.
But as I have said many times now - only visible very seldomly.
Given that nobody has used that solution so far, how do you know?
And we have a lot of prefixes now, so it is pretty reasonable to expect lots of ugly colons to look at after the change. And if I want to
I disagree, I would say it is pretty reasonable to not expect lots of them. But this I intend to demonstrate in fact, so we will see.
I'd be a really interested in seeing an experiment along those lines.
GemStone thus has shadowing - the spaces are like layers on top of each other - a space early in the array can shadow a space later. Good? IMHO it would just get confusing and error prone *in the context of Squeak* . I simply don't see the need for shadowing like this - others may disagree - read on for an interesting side effect.
Yea, I think we could live without this part in the base.
Eh, but that is an INTEGRAL part of the GemStone setup. That is the whole idea with having a LIST in the first place. If you don't want shadowing then you land on my proposal. :)
Huh? And why would that be? I fail to see why not having shadowing necessarily ends up with your proposal - I can imagine various namespace implementations not having shadowing and not being the same as yours.
And I am with you on not making namespaces so granular. Sometimes, even with python, if the problem is small enough most of the code is import statements. One of the things I like about smalltalk is that it isn't like that.
I don't find that an advantage considering the alternative of a single humongous namespace that you have to probe for trying to find an unused name for your project. In particular if it is (like in Python) coupled with stating the dependencies, e.g., the packages that you are going to require.
Cheers, - Andreas
Hi!
goran@krampe.se wrote:
Eh, IMHO they are just as much "namespaces" as any other kind. And moving to a multiple-dicts internal implementation - which I btw considered - is much, much harder. In fact, Andreas told me to just don't go there - it is a world of hurt.
Well, I don't think that is *quite* what I said (unless you have a quote to back it up ;-)
Yes, those were not your exact words, didn't mean that. :)
but generally, yes, complex means of searching nested namespaces can get problematic very quickly. If anything, that was one of the lessons I took away from the 3.3 modules where effectively everything always included everything else and wanting to "not-include" anything became an outright adventure. But I do think there are a few ways to make that search mechanism explicit and clear (for example, by avoiding transitive import chains).
Yeah, I presume there are multiple models that are simple enough to be viable as a "next step" for Smalltalkers - I just haven't seen much need for a more elaborate model - given that as we all know prefixes has served us "kinda ok" up to now and that I have lots of fear for taking away the "Smalltalk feel".
When people argue for "nested" spaces I would like to hear the actual semantics intended. In other words - what does the child-parent relationship mean? Is it that a child sees the same stuff that its parent sees? Or is it that if you import the parent you also implicitly import the child? Or the reverse? Or is it merely for organisational purposes?
I don't think that is at all clear. In java it seems to only serve two purposes - organisational and an decreased probability of picking the same "namespace name" that someone else has done.
With your set up, every class that is in a namespace has to have some ugly colon syntax.
But as I have said many times now - only visible very seldomly.
Given that nobody has used that solution so far, how do you know?
I consider it to be a fair guess given the "rules" for when it is needed to be shown. But yes, I will try to set up an experiment and we will see.
I'd be a really interested in seeing an experiment along those lines.
Will see when I get the time.
GemStone thus has shadowing - the spaces are like layers on top of each other - a space early in the array can shadow a space later. Good? IMHO it would just get confusing and error prone *in the context of Squeak* . I simply don't see the need for shadowing like this - others may disagree - read on for an interesting side effect.
Yea, I think we could live without this part in the base.
Eh, but that is an INTEGRAL part of the GemStone setup. That is the whole idea with having a LIST in the first place. If you don't want shadowing then you land on my proposal. :)
Huh? And why would that be? I fail to see why not having shadowing necessarily ends up with your proposal - I can imagine various namespace implementations not having shadowing and not being the same as yours.
I meant that the GemStone model described - minus the *list* of namespaces (thus making them on equal footing) - ends up being more or less my model AFAICT.
It was not a general claim for all possible models using shadowing. ;)
And I am with you on not making namespaces so granular. Sometimes, even with python, if the problem is small enough most of the code is import statements. One of the things I like about smalltalk is that it isn't like that.
I don't find that an advantage considering the alternative of a single humongous namespace that you have to probe for trying to find an unused name for your project. In particular if it is (like in Python) coupled with stating the dependencies, e.g., the packages that you are going to require.
This is of course debatable. Btw, the variation of allowing nested spaces in my proposal (as you do in Croquet I guess) is not impossible. I just think it would be nice to avoid if possible.
For example (thinking aloud) one could envision allowing nested spaces and then use that to group names that are "private" to the namespace versus those that are not private. Or "Shy" as I have called it before - meaning that the "shy names" don't participate as candidates in the pop up menu when you type a short name. Let's say we have:
Impara::Croquet::Shy::Component Impara::Croquet::SomeClass Seaside::Component Foo::SomeClass
Typing "SomeClass" in a method in Bar::MyClass would ask me which one I mean - because there are two "non local" such names in the image.
Typing "Component" in a method in Bar::MyClass would resolve without asking to Seaside::Component and not involve the shy Croquet class.
One argument for using the term "Shy" instead of "Private" is of course that it is just as accessible as any other name - if you refer to it more explicitly.
As I said, only "thinking aloud". :) In the above variation allowing nested spaces the child-parent would not have any semantics other than being used in the "policy" of when to show names short and when to ask which name you actually meant.
So the above model would be extremely easy to add to my proposal - I think. I am not arguing in favor of it though. :)
regards, Göran
From: goran@krampe.se 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: Tue, 5 Dec 2006 00:04:36 +0200
Comparing those two I am definitely in favor of :: - but note that the Gemstone style works too - but then it is a runtime lookup and not a compile time lookup - which is pretty intuitive IMHO.
afaik, it is a compile time look up same as yours. "Compile" being when you make a method and say "accept" or when you file something in (which explains why code would run different depending on who loads it). At least that's how I understand it.
_________________________________________________________________ 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...
Hi!
"J J" azreal1977@hotmail.com wrote:
From: goran@krampe.se Comparing those two I am definitely in favor of :: - but note that the Gemstone style works too - but then it is a runtime lookup and not a compile time lookup - which is pretty intuitive IMHO.
afaik, it is a compile time look up same as yours. "Compile" being when you make a method and say "accept" or when you file something in (which explains why code would run different depending on who loads it). At least that's how I understand it.
Let me rephrase that:
"Comparing those two I am definitely in favor of :: - but note that the Gemstone style works *in my proposal too* - but then it would be a normal runtime lookup and not a compile time lookup - which *given the syntax* is pretty intuitive IMHO."
Or in other words - in my proposal writing:
Foo at: #Bar
...is just regular Smalltalk, nothing magical at all. Foo refers to a Namespace held in a global. And I prefer that because it *looks* like regular Smalltalk. But if you see :: - then you get a heads up, which is good - since it is a new concept.
But in GemStone, if I understood it correctly, the Compiler is fed... a list of System Dicts? Not sure exactly, but in any case "Foo" can be resolved differently at compile time because of that. I can easily see all newbies and experts alike fall over that one over and over and over...
Now - if you are worried about changing syntax - I would actually consider the GemStone difference much more "dangerous". :)
regards, Göran
From: goran@krampe.se 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: Tue, 5 Dec 2006 21:58:49 +0200
Hi!
Let me rephrase that:
"Comparing those two I am definitely in favor of :: - but note that the Gemstone style works *in my proposal too* - but then it would be a normal runtime lookup and not a compile time lookup - which *given the syntax* is pretty intuitive IMHO."
Ah I get it. Yes that is true, their implementation is some what magical. Though no more magical then #ifTrue:ifFalse end up being.
Now - if you are worried about changing syntax - I would actually consider the GemStone difference much more "dangerous". :)
Honestly, as petty as it sounds, I just care about the colons. I look at a class definition and I have to see that. To me it would feel more smalltalk to just see an extra "NameSpace:" keyword in the class definition and "(MyNameSpace at: #Component) new" for explicit class instantiation (i.e. when you need a class outside of your local namespace). In fact that feels a *lot* more smalltalkish to me.
But anyway, that is just my opinion. If you end up doing it can it at least be unloadable? :) Nothing against you personally of course. I just find it ugly. The only thing worse would be dollar signs on the variable names or something.
_________________________________________________________________ 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...
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:04:00 +0100 (CET)
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.
Yes, but here is the difference I see: Right now we have MCDictionary (ok we probably don't, but as an example) and Dictionary. When I see MCDictionary, no problem, I know its for MC. And when I see Dictionary I know it's a pure dictionary. But with your solution, yes it stays like now *for the moment*. But you made this to get used. Which means the MC people will want to change MCDictionary to MC::Dictionary. What happens then? MC::Dictionary gets only slightly (to my eyes) uglier, but now all my uses of Dictionary become Kernel::Dictionary. Right? That's what I don't want. I realize I don't have to *type* it, but I don't want to *see* it. It is line noise for me.
I agree. And yes, there is a cost. But people seem to think that we have these choices:
- 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).
I'm with you on the complexity of imports. I know it can really suck in other languages. And in smalltalk I think it would be one of the rare things that is *more* problematic then for other languages because you are looking at a method at a time. You would have to put the import statements somewhere else (I think Andreas suggested with the package) and then simply remember them since you can't see it anymore. Or keep two browsers open for every class you edit.
So it is a complicated problem end to end. Of everything I have heard I think the Gemstone (I think it was) solution was the best over all. It still has the problems with extra burden for programmer memory but you get a lot with it at least.
- Live on with "manual" namespaces using prefixes that doesn't enable any
proper tool support. We have them ALREADY - don't deny it.
Who denies it? I think the disconnect here is simply: you see this as a huge, almost show-stopper level problem. I personally see it as a minor annoyance that actually gets amazingly close while still looking nice and being explicit/obvious (i.e. less burden for the reader, and we all know code is read much more then written). I personally don't want the look of (to me) a beautiful language to change for pain I just don't feel.
- 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.
If the solution is right it will have a good chance to get adopted I would think. Traits was a pretty big change, but it fixed a real problem with some huge pain. And also, it hasn't changed how most of Squeak looks afaik.
_________________________________________________________________ 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...
Hi!
From: Göran Krampe goran@krampe.se 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.
Yes, but here is the difference I see: Right now we have MCDictionary (ok we probably don't, but as an example) and Dictionary. When I see MCDictionary, no problem, I know its for MC. And when I see Dictionary I know it's a pure dictionary. But with your solution, yes it stays like now *for the moment*. But you made this to get used. Which means the MC people will want to change MCDictionary to MC::Dictionary. What happens then? MC::Dictionary gets only slightly (to my eyes) uglier, but now all my uses of Dictionary become Kernel::Dictionary. Right? That's what I don't want.
As I posted a minute ago - no, it would stay Dictionary.
I agree. And yes, there is a cost. But people seem to think that we have these choices:
- 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).
I'm with you on the complexity of imports. I know it can really suck in other languages. And in smalltalk I think it would be one of the rare things that is *more* problematic then for other languages because you are looking at a method at a time. You would have to put the import statements somewhere else (I think Andreas suggested with the package) and then simply remember them since you can't see it anymore. Or keep two browsers open for every class you edit.
Exactly. And there are other issues - like for example the fact that writing a snippet in a Workspace (or any other text area) suddenly needs to know what imports it is supposed to use...
So it is a complicated problem end to end. Of everything I have heard I think the Gemstone (I think it was) solution was the best over all. It still has the problems with extra burden for programmer memory but you get a lot with it at least.
- Live on with "manual" namespaces using prefixes that doesn't enable
any proper tool support. We have them ALREADY - don't deny it.
Who denies it? I think the disconnect here is simply: you see this as a huge, almost show-stopper level problem. I personally see it as a minor annoyance that actually gets amazingly close while still looking nice and being explicit/obvious (i.e. less burden for the reader, and we all know code is read much more then written). I personally don't want the look of (to me) a beautiful language to change for pain I just don't feel.
It sounds like the "look" will be changed dramatically. We are only stuffing in '::' between the prefix and the rest. It is not a HUGE difference you know. :)
- 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.
If the solution is right it will have a good chance to get adopted I would think.
Hehe, the problem with that line of thought is that "is right" is subjective. The more complex solution the likelier it will piss off tons of Squeakers that will stop it dead on squeak-dev.
Traits was a pretty big change, but it fixed a real problem with some huge pain.
Really? A huge pain? I agree that Traits are great etc, but I would not say that we had "huge pain" before we got them.
And also, it hasn't changed how most of Squeak looks afaik.
That is just because they aren't used yet. :)
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: Fri, 1 Dec 2006 08:59:10 +0100 (CET)
Who denies it? I think the disconnect here is simply: you see this as
a
huge, almost show-stopper level problem. I personally see it as a minor annoyance that actually gets amazingly close while still looking nice
and
being explicit/obvious (i.e. less burden for the reader, and we all know code is read much more then written). I personally don't want the look
of
(to me) a beautiful language to change for pain I just don't feel.
It sounds like the "look" will be changed dramatically. We are only stuffing in '::' between the prefix and the rest. It is not a HUGE difference you know. :)
Well, I would just find seeing that everywhere in my smalltalk code very ugly. And looks of code do matter. We are trained from a young age not to look at ugly things more then we must.
Really? A huge pain? I agree that Traits are great etc, but I would not say that we had "huge pain" before we got them.
Yes, the inheritance model without them has some real problems. And finding a solution is tough. C++'s multiple inheritance? Too complicated. Java's interfaces? Too much work and code duplication. So now smalltalk has a solution, and IMO the best one.
_________________________________________________________________ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get...
Hi!
"J J" azreal1977@hotmail.com wrote:
Who denies it? I think the disconnect here is simply: you see this as
a
huge, almost show-stopper level problem. I personally see it as a minor annoyance that actually gets amazingly close while still looking nice
and
being explicit/obvious (i.e. less burden for the reader, and we all know code is read much more then written). I personally don't want the look
of
(to me) a beautiful language to change for pain I just don't feel.
It sounds like the "look" will be changed dramatically. We are only stuffing in '::' between the prefix and the rest. It is not a HUGE difference you know. :)
Well, I would just find seeing that everywhere in my smalltalk code very ugly. And looks of code do matter. We are trained from a young age not to look at ugly things more then we must.
Ehm, everywhere? I am not sure you have understood this proposal - the likely effect is that you will almost NEVER see any of those :: in actual code. You will see them in class definitions though.
Recall that they are only showed when there is a *conflict*.
Really? A huge pain? I agree that Traits are great etc, but I would not say that we had "huge pain" before we got them.
Yes, the inheritance model without them has some real problems. And finding a solution is tough. C++'s multiple inheritance? Too complicated. Java's interfaces? Too much work and code duplication. So now smalltalk has a solution, and IMO the best one.
As Avi posted - are you basing this on experience? Because most experienced Smalltalkers have almost never felt any pressing need for them. Sure, they are nifty - and they can improve on design - but a "huge pain"? Nah.
regards, Göran
From: goran@krampe.se 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 10:43:18 +0200
Ehm, everywhere? I am not sure you have understood this proposal - the likely effect is that you will almost NEVER see any of those :: in actual code. You will see them in class definitions though.
Recall that they are only showed when there is a *conflict*.
My point was was that after a few years of use conflicts will be everywhere. But I suppose the tools can be set up to, for example, not show the :: ever but do it on mouse-over or something. I guess I could live with that.
As Avi posted - are you basing this on experience? Because most experienced Smalltalkers have almost never felt any pressing need for them. Sure, they are nifty - and they can improve on design - but a "huge pain"? Nah.
Ok, they don't solve a huge pain as in something that bites us every day. But more of a huge pain as in a fundamental problem with OO systems when they get larger. And since one of the main points of OO development was to be able to develop very large systems, I count that as a huge pain.
_________________________________________________________________ Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
+1
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 00:14:11 -0800
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
_________________________________________________________________ Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
On 11/29/06, Bert Freudenberg bert@freudenbergs.de 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.
I don't know what to think of the syntax; it smells a bit like C++. I prefer dotted namespaces, but that's quite subjective and not really a killer issue.
I disagree with the implementation. I personally think that the Smalltalk SystemDictionary should be split up into multiple, nested Namespaces (which are subclasses of Dictionary). These would have some mechanism, such as import lists, to glue them together. At this stage, I don't have a well-thought out alternative proposal.
The proposed implementation also doesn't solve one of the problems that Namespaces could solve: security. I'm writing a distributed environment that provides a sandbox for remote code; the remote code must be denied access to the SystemDictionary for securities' sake. Instead, remotely loaded code should only have access to particular Classes and "global variables" in the Namespaces that the remote code has access to. The namespace of a particular class could be stored in the class's "environment" variable.
I suppose it doesn't really matter; if I use the same notation and semantics for resolving classes and global variables, then code would continue to compile under both this proposal and an alternate namespacing implementation that I'll be writing.
Michael.
Michael's description is something like what GemStone/Smalltalk provides-each login is assigned an array of SymbolDictionary instances (a SymbolList), and compiling is in the context of a SymbolList. You can have multiple globals visible with the same name, but the first one found is used. Different code can be compiled with different instances of SymbolList, and multiple instances of SymbolList can reference the same SymbolDictionary. Security can be addressed by giving a user a SymbolList that does not reference things that should be hidden.
James Foster
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Michael van der Gulik Sent: Wednesday, November 29, 2006 6:32 PM To: The general-purpose Squeak developers list Subject: Re: Squeak and Namespaces
On 11/29/06, Bert Freudenberg bert@freudenbergs.de 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.
I don't know what to think of the syntax; it smells a bit like C++. I prefer dotted namespaces, but that's quite subjective and not really a killer issue.
I disagree with the implementation. I personally think that the Smalltalk SystemDictionary should be split up into multiple, nested Namespaces (which are subclasses of Dictionary). These would have some mechanism, such as import lists, to glue them together. At this stage, I don't have a well-thought out alternative proposal.
The proposed implementation also doesn't solve one of the problems that Namespaces could solve: security. I'm writing a distributed environment that provides a sandbox for remote code; the remote code must be denied access to the SystemDictionary for securities' sake. Instead, remotely loaded code should only have access to particular Classes and "global variables" in the Namespaces that the remote code has access to. The namespace of a particular class could be stored in the class's "environment" variable.
I suppose it doesn't really matter; if I use the same notation and semantics for resolving classes and global variables, then code would continue to compile under both this proposal and an alternate namespacing implementation that I'll be writing.
Michael.
On 11/30/06, James Foster james@foster.net wrote:
Michael's description is something like what GemStone/Smalltalk provides—each login is assigned an array of SymbolDictionary instances (a SymbolList), and compiling is in the context of a SymbolList. You can have multiple globals visible with the same name, but the first one found is used. Different code can be compiled with different instances of SymbolList, and multiple instances of SymbolList can reference the same SymbolDictionary. Security can be addressed by giving a user a SymbolList that does not reference things that should be hidden.
That sounds interesting.
- How do you specify that. rather than the first global found, you want to use a different global with the same name?
- Can SymbolDictionaries be nested? I.e. Collections::Sequenceable::OrderedCollection?
Michael.
In GemStone/Smalltalk rather than having a single SymbolDictionary (Smalltalk) that contains all the globals, there is a list of SymbolDictionary instances each of which is examined to see if it has the key being referenced. There is no built-in support for nesting-just an Array of SymbolDictionary instances instead of a single SymbolDictionary instance.
The code:
myTest := TestCase new.
Is equivalent to:
myTest := (System myUserProfile symboList resolveSymbol: #'TestCase') value new.
By convention, each SymbolDictionary instance is contained in itself as a value where the key is its "name." For example, filing in the SUnit package results in creation of a new SymbolDictionary whose initial key is #'SUnit' with the new SymbolDictionary instance as its value. The new SymbolDictionary instance is added as the first entry in the current SymbolList instance (so that any other globals with identical names are effectively hidden), and then the file-in proceeds adding various keys including #'TestCase', #'TestResource', #'TestResult', and #'TestSuite' (each of which has an associated value that is the named class).
If I wanted to be more particular about the lookup in the above code example, I could specify:
myTest := (SUnit at: #'TestCase') new.
Or, to be more specific:
myTest := ((System myUserProfile symboList at: 2) at: #'TestCase') new.
Or, to be more specific still:
myTest := (((AllUsers userWithId: 'JamesFoster') symbolList at: 2) at: #'TestCase') new.
Importantly, there is no change in the language syntax. The "magic" happens during method compilation where one of the arguments to the compiler is the SymbolList instance that is to be searched for any needed global references. Different methods can be compiled with reference to different SymbolList instances, and still call each other. This allows for private classes, class replacement, etc. It has served reasonably well for a couple decades.
James Foster
-----Original Message----- From: Michael van der Gulik [mailto:mikevdg@gmail.com] Sent: Wednesday, November 29, 2006 8:52 PM To: james@foster.net; The general-purpose Squeak developers list Subject: Re: Squeak and Namespaces
On 11/30/06, James Foster james@foster.net wrote:
Michael's description is something like what GemStone/Smalltalk provides-each login is assigned an array of SymbolDictionary instances (a SymbolList), and compiling is in the context of a SymbolList. You can have multiple globals visible with the same name, but the first one found is used. Different code can be compiled with different instances of SymbolList, and multiple instances of SymbolList can reference the same SymbolDictionary. Security can be addressed by giving a user a SymbolList that does not reference things that should be hidden.
That sounds interesting.
- How do you specify that. rather than the first global found, you want to use a different global with the same name?
- Can SymbolDictionaries be nested? I.e. Collections::Sequenceable::OrderedCollection?
Michael.
From: "James Foster" james@foster.net Reply-To: james@foster.net, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'Michael van der Gulik'" mikevdg@gmail.com CC: 'The general-purpose Squeak developers list'squeak-dev@lists.squeakfoundation.org Subject: RE: Squeak and Namespaces Date: Wed, 29 Nov 2006 21:58:49 -0800
Importantly, there is no change in the language syntax. The "magic" happens during method compilation where one of the arguments to the compiler is the SymbolList instance that is to be searched for any needed global references. Different methods can be compiled with reference to different SymbolList instances, and still call each other. This allows for private classes, class replacement, etc. It has served reasonably well for a couple decades.
This is all very interesting. So I guess the given user has to be explicitly set up to use any namespace they get? And if one is added you rebuild all the places the user is being implicit since he may now be talking about a totally different class even though his code didn't change?
_________________________________________________________________ Stay up-to-date with your friends through the Windows Live Spaces friends list. http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spa...
Hi,
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of J J Sent: Wednesday, November 29, 2006 10:21 PM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Squeak and Namespaces
From: "James Foster" james@foster.net Reply-To: james@foster.net, The general-purpose Squeak developers listsqueak-dev@lists.squeakfoundation.org To: "'Michael van der Gulik'" mikevdg@gmail.com CC: 'The general-purpose Squeak developers list'squeak-dev@lists.squeakfoundation.org Subject: RE: Squeak and Namespaces Date: Wed, 29 Nov 2006 21:58:49 -0800
Importantly, there is no change in the language syntax. The "magic"
happens
during method compilation where one of the arguments to the compiler is
the
SymbolList instance that is to be searched for any needed global references. Different methods can be compiled with reference to different SymbolList instances, and still call each other. This allows for private classes, class replacement, etc. It has served reasonably well for a couple decades.
This is all very interesting. So I guess the given user has to be explicitly set up to use any namespace they get?
By default, the existing tools that create a new user give the new user a specified subset of the existing SymbolDictionary instances.
And if one is added you rebuild all the places the user is being implicit since he may now be talking about a totally different class even though his code didn't change?
If a new SymbolDictionary is added to the image then it is not visible to a user till it is added to that user's SymbolList. Adding it to a user's SymbolList only impacts methods that are compiled later. Compiled code remains bound to the globals (Association) referenced when the methods were compiled. If you wanted to change the bindings, you would need to recompile the methods.
James
On 11/28/06, Klaus D. Witzel klaus.witzel@cobss.com 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
+1
Hi Aaron,
as can already seen from this thread, (Squeak times: Namespaces) seems to be not easy because multiple requirements may clash.
We should define how namespaces work, my suggestion:
- concept: a class defines a namespace, is authoritative - atoms: classes and [parts of] their state are atomic namespaces
= "namestate"
- composition: a namespace is a container with 1:n components, a namestate is a component with 1:1 container - uniqueness: a namestate and its full name are unique, its atomic name *must* not
There *should* be some syntactical emphasis so that the developer (and Shout) can understand!
Motivation for syntax: we say SmallInteger and LargeInteger to subclasses of Integer and obviously prefer the opposite direction for a namespace hierarchy. Let's replace the suggested :: by a legitimate binary message
Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
The compiler *should* be extendable by a namespace/namestate implementation. Of course the implementation of #>~ depends on the run-time used (VW, Squeak, etc) and the default implementation is DNU (for Xtreme speed of development ;-)
And Class#>~ can be overridden in support of specialized namestate resolution during fileIn and accept (I mean alt-s in the browser).
My CHF 0.05 :)
/Klaus
P.S. in the above, nothing much is new.
P.P.S. if I had a whish free then I'd like to drag'n'drop namestate in the browser (Andreas' step towards enabling scalability of development).
On Tue, 21 Nov 2006 17:32:10 +0100, Aaron Reichow revaaron@bitquabit.com 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?
I ask because it seems that, to me, it would be relatively easy to implement an intelligent namespace system in Squeak, something we all could decide on. It could even offer backwards compatibility in that, for now, all the classes in the image are just part of the default namespace, that way nothing gets broken.
Ideas? Thoughts? Maybe a pointer to a discussion where this was already hashed out? Thanks!
Regards, Aaron
On 11/29/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Motivation for syntax: we say SmallInteger and LargeInteger to subclasses of Integer and obviously prefer the opposite direction for a namespace hierarchy. Let's replace the suggested :: by a legitimate binary message
Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
Implementing Namespaces like this would mean that your code runs slower. In order to refer to a class, you'll need to send a message to a Namespace every time you refer to it, rather than just refer to the class directly.
Also, your message names are capitalised, which will have a negative affect on your karma.
Michael.
Il giorno gio, 30/11/2006 alle 12.07 +1300, Michael van der Gulik ha scritto:
On 11/29/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Motivation for syntax: we say SmallInteger and LargeInteger to subclasses of Integer and obviously prefer the opposite direction for a namespace hierarchy. Let's replace the suggested :: by a legitimate binary message Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
Implementing Namespaces like this would mean that your code runs slower. In order to refer to a class, you'll need to send a message to a Namespace every time you refer to it, rather than just refer to the class directly.
Also, your message names are capitalised, which will have a negative affect on your karma.
Isn't this what Henryk's Environments do?
Giovanni
Hi!
Giovanni Corriga giovanni@corriga.net wrote:
Il giorno gio, 30/11/2006 alle 12.07 +1300, Michael van der Gulik ha scritto:
On 11/29/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Motivation for syntax: we say SmallInteger and LargeInteger to subclasses of Integer and obviously prefer the opposite direction for a namespace hierarchy. Let's replace the suggested :: by a legitimate binary message Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
Implementing Namespaces like this would mean that your code runs slower. In order to refer to a class, you'll need to send a message to a Namespace every time you refer to it, rather than just refer to the class directly.
Also, your message names are capitalised, which will have a negative affect on your karma.
Isn't this what Henryk's Environments do?
Henrik, not Henryk. And I would probably say Dan's/Henrik's Environments - Dan started that path and Henrik tried to fulfil it.
Personally I think it is too complicated - I dislike hierarchies in general :). But yes, the idea was to use late binding using message sends etc.
In fact, using my Namespaces you can do both I guess. We could implement a DNU on class Namespace and that would be it. They are already reified globals hanging in Smalltalk under their own name.
And right, I started on that Detailed walktrough I promised - but I only got through the "core" part and actually found an issue and also need to study some parts of it more to get it all nailed down. If you file that core part into say a 3.7 image the idea was that you could then create classes like Foo::Bar and use them (and thus be able to file in new code written with these namespaces). But the method #scopeVariable needs to be different for this to work - it expects to find an instance of Namespace called #Foo in Smalltalk - which of course will not be there.
But here is the current draft:
http://swiki.krampe.se/gohu/35
regards, Göran
Hi G"oran,
on Thu, 30 Nov 2006 01:19:41 +0100, you wrote:
Hi! Giovanni Corriga giovanni@corriga.net wrote:
Il giorno gio, 30/11/2006 alle 12.07 +1300, Michael van der Gulik ha scritto:
On 11/29/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Motivation for syntax: we say SmallInteger and LargeInteger to subclasses of Integer and obviously prefer the opposite direction for a namespace hierarchy. Let's replace the suggested :: by a legitimate binary message Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
Implementing Namespaces like this would mean that your code runs slower. In order to refer to a class, you'll need to send a message to a Namespace every time you refer to it, rather than just refer to the class directly.
Also, your message names are capitalised, which will have a negative affect on your karma.
Isn't this what Henryk's Environments do?
Henrik, not Henryk. And I would probably say Dan's/Henrik's Environments
- Dan started that path and Henrik tried to fulfil it.
Personally I think it is too complicated - I dislike hierarchies in general :).
My mistake: I wrote "hierarchy" but in fact the space is organized like the space in Trait (users of a trait composition and the composition's components).
But yes, the idea was to use late binding using message sends etc.
No, this was not my idea. The compiler reduces the #>~ message symbol:
(A >~ B) "results in" (Association key: #B value: B) "which is a component of A"
For namespace maintenance:
(A >~ B) moveToNamespace: C. "next line still refers to same B" (A >~ B) namespace shallowCopy moveToNamespace: D. (C >~ B) = (D >~ B) "true"
/Klaus
In fact, using my Namespaces you can do both I guess. We could implement a DNU on class Namespace and that would be it. They are already reified globals hanging in Smalltalk under their own name.
And right, I started on that Detailed walktrough I promised - but I only got through the "core" part and actually found an issue and also need to study some parts of it more to get it all nailed down. If you file that core part into say a 3.7 image the idea was that you could then create classes like Foo::Bar and use them (and thus be able to file in new code written with these namespaces). But the method #scopeVariable needs to be different for this to work - it expects to find an instance of Namespace called #Foo in Smalltalk - which of course will not be there.
But here is the current draft:
http://swiki.krampe.se/gohu/35
regards, Göran
No, this was not my idea. The compiler reduces the #>~ message symbol:
(A >~ B) "results in" (Association key: #B value: B) "which is a component of A"
For namespace maintenance:
(A >~ B) moveToNamespace: C. "next line still refers to same B" (A >~ B) namespace shallowCopy moveToNamespace: D. (C >~ B) = (D >~ B) "true"
/Klaus
So would it be possible to
a) remove the 'bug' which allows ':' in Class names, and b) allow the binary operator shown above to be '::'?
#>~ seems rather naff #>> would make some sense to me but is used by Integer for shifting, so I guess it would not be available.
cheers
Keith
___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html
Hi Keith,
on Thu, 30 Nov 2006 03:33:42 +0100, you wrote:
Klaus wrote:
No, this was not my idea. The compiler reduces the #>~ message symbol:
(A >~ B) "results in" (Association key: #B value: B) "which is a component of A"
For namespace maintenance:
(A >~ B) moveToNamespace: C. "next line still refers to same B" (A >~ B) namespace shallowCopy moveToNamespace: D. (C >~ B) = (D >~ B) "true"
/Klaus
So would it be possible to
a) remove the 'bug' which allows ':' in Class names, and
Sure. Get rid of it.
b) allow the binary operator shown above to be '::'?
In principle: yes. Except for #Aselector: and Aclass, which can be mistaken (next line is a bug) for
Aselector::Aclass
#>~ seems rather naff #>> would make some sense to me but is used by Integer for shifting, so I guess it would not be available.
I won't care as long as colons are explicitly reserved for the argument concept. From the GOF designers point of view, *either* a selector has special character(s) *or* the argument(s) are delimited by a special character (colon for the latter) - and no whitespace allowed, like in negative examples (3 + = 4) and (key : value).
This "special character *or colon* accompanies *every* argument position" message of Smalltalk was always evangelistic clear to me. We don't have #(( or #[[ or #^^ or #__ or #.. and I hope the same for the #:: symbol.
/Klaus
cheers
Keith
Hi!
Hi G"oran,
on Thu, 30 Nov 2006 01:19:41 +0100, you wrote:
Hi! Giovanni Corriga giovanni@corriga.net wrote:
Il giorno gio, 30/11/2006 alle 12.07 +1300, Michael van der Gulik ha scritto:
On 11/29/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Motivation for syntax: we say SmallInteger and LargeInteger
to
subclasses of Integer and obviously prefer the opposite direction for a namespace hierarchy. Let's replace the suggested :: by a legitimate binary message Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
Implementing Namespaces like this would mean that your code runs slower. In order to refer to a class, you'll need to send a message
to
a Namespace every time you refer to it, rather than just refer to the class directly.
Also, your message names are capitalised, which will have a negative affect on your karma.
Isn't this what Henryk's Environments do?
Henrik, not Henryk. And I would probably say Dan's/Henrik's Environments
- Dan started that path and Henrik tried to fulfil it.
Personally I think it is too complicated - I dislike hierarchies in general :).
My mistake: I wrote "hierarchy" but in fact the space is organized like the space in Trait (users of a trait composition and the composition's components).
You lost me. You have "System >~ Default >~ Compiler" - that is a path down a hierarchy, right?
But yes, the idea was to use late binding using message sends etc.
No, this was not my idea. The compiler reduces the #>~ message symbol:
Ok, but it was in Henrik's/Dan's code. :)
(A >~ B) "results in" (Association key: #B value: B) "which is a component of A"
Eh... so you do compile time binding just like I do? Then what was the point of using a "binary message"? Just syntactic?
regards, Göran
On Thu, 30 Nov 2006 10:17:41 +0100, G"oran wrote:
Hi!
Hi G"oran, on Thu, 30 Nov 2006 01:19:41 +0100, you wrote:
Hi! Giovanni Corriga giovanni@corriga.net wrote:
Il giorno gio, 30/11/2006 alle 12.07 +1300, Michael van der Gulik ha
Also, your message names are capitalised, which will have a negative affect on your karma.
Isn't this what Henryk's Environments do?
Henrik, not Henryk. And I would probably say Dan's/Henrik's Environments
- Dan started that path and Henrik tried to fulfil it.
Personally I think it is too complicated - I dislike hierarchies in general :).
My mistake: I wrote "hierarchy" but in fact the space is organized like the space in Trait (users of a trait composition and the composition's components).
You lost me. You have "System >~ Default >~ Compiler" - that is a path down a hierarchy, right?
Inasmuch as containers and components form a hierarchy: yes. Inasmuch as the atom of a hierarchy can always root a subhierarchy versus, an atom of a namespace can always be subdivided: no.
Suggestion: you take the branch marked with *yes* :)
But yes, the idea was to use late binding using message sends etc.
No, this was not my idea. The compiler reduces the #>~ message symbol:
Ok, but it was in Henrik's/Dan's code. :)
:)
(A >~ B) "results in" (Association key: #B value: B) "which is a component of A"
Eh... so you do compile time binding just like I do? Then what was the point of using a "binary message"? Just syntactic?
Partially; more specific: an attempt to use the same syntax for coding and for maintenance (for doIt and friends) which *also* can be overridden (specialized) at will (like, for example, in the Smalltalk language every method can be overridden at will :)
In this particular discussion, I mean *not* to override your #scopeVariable method in Parser. Instead, here's the difference:
binding := scope perform: #>~ with: varName asSymbol "cannot just send >~ here ;-)"
Note the difference between #bindingOf: and #>~ (the latter is a binary message, suitable for easy doIt).
/Klaus
regards, Göran
Hi Michael,
on Thu, 30 Nov 2006 00:07:24 +0100, you wrote:
On 11/29/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Motivation for syntax: we say SmallInteger and LargeInteger to subclasses of Integer and obviously prefer the opposite direction for a namespace hierarchy. Let's replace the suggested :: by a legitimate binary message
Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
Implementing Namespaces like this would mean that your code runs slower.
Why should it? There are 2 possibilities:
1 - the compiler does not know about #>~ and so compiles a message send which results in DNU.
2 - it does know, then is compiles the usual reference to a literal variable (name being resolved at compile-time: that's the magic behind namespace+compiler).
In order to refer to a class, you'll need to send a message to a Namespace every time you refer to it, rather than just refer to the class directly.
By no means, only the compiler has, not me :|
Also, your message names are capitalised,
The word after the >~ is not a message name, it's in argument position (like in the Smalltalk programming lanugage ;-) And the word before the >~ is in argument position, too :) That's the nature of the binary #>~ message (handled by compiler).
which will have a negative affect on your karma.
Not my karma: the compiler's karma ;-)
/Klaus
Michael.
From: "Michael van der Gulik" mikevdg@gmail.com Reply-To: 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 12:07:24 +1300
On 11/29/06, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Morphic >~ View Tweak >~ View System >~ Default >~ Compiler My >~ Terrific >~ Compiler
Implementing Namespaces like this would mean that your code runs slower. In order to refer to a class, you'll need to send a message to a Namespace every time you refer to it, rather than just refer to the class directly.
It wouldn't have to. No matter how the mechanism works, it can be resolved at compile time to point to the actual location of the class, so slightly slower compile but that's it. I can't think of any reason to do such lookups dynamically.
Also, your message names are capitalised, which will have a negative affect on your karma.
Michael.
Well if you see them as Name or Class spaces then I think convention would indicate they should be upper case.
_________________________________________________________________ Get free, personalized commercial-free online radio with MSN Radio powered by Pandora http://radio.msn.com/?icid=T002MSN03A07001
squeak-dev@lists.squeakfoundation.org