Hi folks!
I just read through Michael van der Gulik's page:
http://gulik.pbwiki.com/Namespaces
Just stumbled over it btw, and I have only read it once and wrote down some notes compared to my own little "venture" in this area:
http://swiki.krampe.se/gohu/32
Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and this is mainly addressed to Michael btw.
Namespace comments:
- I personally think hierarchical namespaces is "too much". I opted for single level namespaces and still think that is enough.
- I personally don't like the "." notation for namespaces, especially since we already use "." for statement separation. I still think "::" is the best I have seen, although granted - this is a tiny, tiny detail.
- Imports are done in your code "per Namespace" which is immensely better than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
- I agree that shared pools theoretically could be replaced with Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :)
- Your Namespaces are linked to a Package scheme, I personally would like to keep these concepts separate.
So... to sum it all up:
- You also bind at compile time just like globals are bound now (and just as in my code). No difference. - You also reify the namespaces as instances of Namespace, as I do. No difference, though you intend to nuke SystemDictionary - I don't. - You also have a Dictionary protocol on the Namespaces enabling normal dynamic lookup just as I have. Kinda normal if you reify them as objects of course.
But...
- You go hierarchical, I stayed simple and kept it on one level. - You use ".", I use "::". - Your code use *both* qualified names (long with dot-notation) and non qualified names (short), I *always* use qualified names in the source and only let the tools "render" them short (or accept writing them short) when they are indeed unique or when the user has a policy that allows a lookup - like for example resolving by default to "local names" (in the same Namespace). - You added an explicit import list per Namespace, I opted to not have imports at all. - You coupled Namespaces with Packages, I did not at all go there.
So the big differences are the two last ones - Explicit import lists vs my approach of no-imports-render-and-accept-short-names and mixing it with a package concept vs not doing that. :)
regards, Göran
On 17/09/2007, Göran Krampe goran@krampe.se wrote:
Hi folks!
I just read through Michael van der Gulik's page:
http://gulik.pbwiki.com/Namespaces
Just stumbled over it btw, and I have only read it once and wrote down some notes compared to my own little "venture" in this area:
http://swiki.krampe.se/gohu/32
Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and this is mainly addressed to Michael btw.
Namespace comments:
- I personally think hierarchical namespaces is "too much". I opted for
single level namespaces and still think that is enough.
- I personally don't like the "." notation for namespaces, especially
since we already use "." for statement separation. I still think "::" is the best I have seen, although granted - this is a tiny, tiny detail.
- Imports are done in your code "per Namespace" which is immensely better
than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
- I agree that shared pools theoretically could be replaced with
Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :)
- Your Namespaces are linked to a Package scheme, I personally would like
to keep these concepts separate.
So... to sum it all up:
- You also bind at compile time just like globals are bound now (and just
as in my code). No difference.
- You also reify the namespaces as instances of Namespace, as I do. No
difference, though you intend to nuke SystemDictionary - I don't.
- You also have a Dictionary protocol on the Namespaces enabling normal
dynamic lookup just as I have. Kinda normal if you reify them as objects of course.
But...
- You go hierarchical, I stayed simple and kept it on one level.
- You use ".", I use "::".
- Your code use *both* qualified names (long with dot-notation) and non
qualified names (short), I *always* use qualified names in the source and only let the tools "render" them short (or accept writing them short) when they are indeed unique or when the user has a policy that allows a lookup
- like for example resolving by default to "local names" (in the same
Namespace).
- You added an explicit import list per Namespace, I opted to not have
imports at all.
- You coupled Namespaces with Packages, I did not at all go there.
So the big differences are the two last ones - Explicit import lists vs my approach of no-imports-render-and-accept-short-names and mixing it with a package concept vs not doing that. :)
regards, Göran
It was me, who proposed Michael van der Gulik's to add package dependencies. Besides Namespaces, keeping package dependencies is important thing to make single image holding every known package in squeak universe (by universe i mean all known forks, which currently forced to keep own separated development branches and cannot be used with single image due to many conflicts). With package hierarchies, you can have image working with different forks, and even interoperate them.
The idea was to keep own namespace(i.e. - globals and behaviors) for each package, and also keep a list of imported packages. Only single package should not have any imports - its a Kernel package. Any others have at least Kernel in imports. Now, how things going on: suppose you making own package and want to modify some classes/methods in package(s) you import. When you making changes, they going not to imported package, but in your package instead. This is much likely you adding an extensions with MC (adding category *MyPackage extensions to foreign class), but in much more clever way :)
Keeping your changed behaviors and names in own package prevents from creating version conflicts with other packages which using old behaviors/classes. Your changes are visible only to your package or any other packages which importing yours. This is most important feature, which allows us to make different versions of tools to live in same image and coexist without conflicts.
There of course must be a good tools to support development in such environment. Since any changes you making must go to some package (like with changesets), developer must always know to which package he's doing changes. - for any package in system, which haves at least a single export (imported by another package, or marked as a 'release' package), you are unable to modify it contents. Instead, you must keep changes with other package - either by creating a new version of it, or by adding changes to your own package, which make use of it.
An update operation is pretty simple. Suppose i maintainer of package X, which currently imports packages Y 1.0 and Z 1.0. Now i want to update my package to use Y 2.0 and Z 3.0.
I simply clicking 'update imports', and creating a new separate version of my package with replaced imports. Now i can run tests/debug e.t.c. When i considered that all is fine, now i can set it as default 'release' version and publish it.
The overall idea is simple: make your code available/visible only to those who wants to use it (by imports). So, you don't need to harvest entire image to find out source of problem, and you will never fear installing updates , because they are unable to make existing code nonfunctional.
On 9/18/07, Igor Stasenko siguctua@gmail.com wrote:
It was me, who proposed Michael van der Gulik's to add package dependencies. Besides Namespaces, keeping package dependencies is important thing to make single image holding every known package in squeak universe (by universe i mean all known forks, which currently forced to keep own separated development branches and cannot be used with single image due to many conflicts). With package hierarchies, you can have image working with different forks, and even interoperate them.
The idea was to keep own namespace(i.e. - globals and behaviors) for each package, and also keep a list of imported packages. Only single package should not have any imports - its a Kernel package. Any others have at least Kernel in imports. Now, how things going on: suppose you making own package and want to modify some classes/methods in package(s) you import. When you making changes, they going not to imported package, but in your package instead. This is much likely you adding an extensions with MC (adding category *MyPackage extensions to foreign class), but in much more clever way :)
Sorry Igor, but I never implemented having overrides of other Packages' classes in a Package. I can't work out how to do it! If anybody knows how without creating an environment for making obscene spaghetti code, please let me know. I admit this is a great loss to the Smalltalkiness of my approach - you can't add methods to String!
For the meanwhile, a workaround is to copy the package where the overrided method would have been, modify it and update the imports to use it. My packaging system will make sure that the modified package will be loaded and used rather than the original (without modifying the original package which may also be installed in your image).
An update operation is pretty simple. Suppose i maintainer of package
X, which currently imports packages Y 1.0 and Z 1.0. Now i want to update my package to use Y 2.0 and Z 3.0.
I simply clicking 'update imports', and creating a new separate version of my package with replaced imports. Now i can run tests/debug e.t.c. When i considered that all is fine, now i can set it as default 'release' version and publish it.
This will all work. The "update imports" feature will be there soon.
Regards, Gulik
(I think I'll use "Gulik" as a handle considering how many "Michaels" there are in the world).
Well this is quite an interesting proposal in itself, though I would say this is above and beyond what we need for namespaces at the moment (given we currently have none at all). This seems like something that may prove itself to be the way to go in the future. I'm interested to see how it turns out.
On 9/17/07, Igor Stasenko siguctua@gmail.com wrote:
On 17/09/2007, Göran Krampe goran@krampe.se wrote:
Hi folks!
I just read through Michael van der Gulik's page:
http://gulik.pbwiki.com/Namespaces
Just stumbled over it btw, and I have only read it once and wrote down some notes compared to my own little "venture" in this area:
http://swiki.krampe.se/gohu/32
Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and this is mainly addressed to Michael btw.
Namespace comments:
- I personally think hierarchical namespaces is "too much". I opted for
single level namespaces and still think that is enough.
- I personally don't like the "." notation for namespaces, especially
since we already use "." for statement separation. I still think "::" is the best I have seen, although granted - this is a tiny, tiny detail.
- Imports are done in your code "per Namespace" which is immensely better
than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
- I agree that shared pools theoretically could be replaced with
Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :)
- Your Namespaces are linked to a Package scheme, I personally would like
to keep these concepts separate.
So... to sum it all up:
- You also bind at compile time just like globals are bound now (and just
as in my code). No difference.
- You also reify the namespaces as instances of Namespace, as I do. No
difference, though you intend to nuke SystemDictionary - I don't.
- You also have a Dictionary protocol on the Namespaces enabling normal
dynamic lookup just as I have. Kinda normal if you reify them as objects of course.
But...
- You go hierarchical, I stayed simple and kept it on one level.
- You use ".", I use "::".
- Your code use *both* qualified names (long with dot-notation) and non
qualified names (short), I *always* use qualified names in the source and only let the tools "render" them short (or accept writing them short) when they are indeed unique or when the user has a policy that allows a lookup
- like for example resolving by default to "local names" (in the same
Namespace).
- You added an explicit import list per Namespace, I opted to not have
imports at all.
- You coupled Namespaces with Packages, I did not at all go there.
So the big differences are the two last ones - Explicit import lists vs my approach of no-imports-render-and-accept-short-names and mixing it with a package concept vs not doing that. :)
regards, Göran
It was me, who proposed Michael van der Gulik's to add package dependencies. Besides Namespaces, keeping package dependencies is important thing to make single image holding every known package in squeak universe (by universe i mean all known forks, which currently forced to keep own separated development branches and cannot be used with single image due to many conflicts). With package hierarchies, you can have image working with different forks, and even interoperate them.
The idea was to keep own namespace(i.e. - globals and behaviors) for each package, and also keep a list of imported packages. Only single package should not have any imports - its a Kernel package. Any others have at least Kernel in imports. Now, how things going on: suppose you making own package and want to modify some classes/methods in package(s) you import. When you making changes, they going not to imported package, but in your package instead. This is much likely you adding an extensions with MC (adding category *MyPackage extensions to foreign class), but in much more clever way :)
Keeping your changed behaviors and names in own package prevents from creating version conflicts with other packages which using old behaviors/classes. Your changes are visible only to your package or any other packages which importing yours. This is most important feature, which allows us to make different versions of tools to live in same image and coexist without conflicts.
There of course must be a good tools to support development in such environment. Since any changes you making must go to some package (like with changesets), developer must always know to which package he's doing changes.
- for any package in system, which haves at least a single export
(imported by another package, or marked as a 'release' package), you are unable to modify it contents. Instead, you must keep changes with other package - either by creating a new version of it, or by adding changes to your own package, which make use of it.
An update operation is pretty simple. Suppose i maintainer of package X, which currently imports packages Y 1.0 and Z 1.0. Now i want to update my package to use Y 2.0 and Z 3.0.
I simply clicking 'update imports', and creating a new separate version of my package with replaced imports. Now i can run tests/debug e.t.c. When i considered that all is fine, now i can set it as default 'release' version and publish it.
The overall idea is simple: make your code available/visible only to those who wants to use it (by imports). So, you don't need to harvest entire image to find out source of problem, and you will never fear installing updates , because they are unable to make existing code nonfunctional.
-- Best regards, Igor Stasenko AKA sig.
Hi Göran, all.
On 9/17/07, Göran Krampe goran@krampe.se wrote:
Hi folks!
I just read through Michael van der Gulik's page:
http://gulik.pbwiki.com/Namespaces
Just stumbled over it btw, and I have only read it once and wrote down some notes compared to my own little "venture" in this area:
http://swiki.krampe.se/gohu/32
Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and this is mainly addressed to Michael btw.
Namespace comments:
- I personally think hierarchical namespaces is "too much". I opted for
single level namespaces and still think that is enough.
We already have hierarchical categories in Squeak. For example, "Kernel-Chronology-Tests". I'm making hierarchical namespaces available, but you don't have to nest things more than one level deep if you don't like that style.
- I personally don't like the "." notation for namespaces, especially
since we already use "." for statement separation. I still think "::" is the best I have seen, although granted - this is a tiny, tiny detail.
Meh. I like the dots; they look tidy. If you can give me a good reason not to use them then I'm happy to change.
- Imports are done in your code "per Namespace" which is immensely better
than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
- I agree that shared pools theoretically could be replaced with
Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :)
To be honest, I've never really used shared pools, so I don't know much about how they're used. In my conversion (categories->namespaces) code, I turn a shared pool into a sub-namespace of the class they appear in (ooh... that could be a bug...). I haven't tested this yet. For the meanwhile I've left class pools as they are.
- Your Namespaces are linked to a Package scheme, I personally would like
to keep these concepts separate.
(background for people: Package is a subclass of Namespace and forms the root of a namespace hierarchy).
Why is this a bad thing? Could you be more specific?
If anybody is interested, an old and very buggy version is available on the PackageUniverses. Install the "NamespacesBrowser" package and then evaluate "NamespaceBrowser example" (IIRC?) to open it. Newer versions which work better are available at http://www.squeaksource.com/SecureSqueak.
Currently, I can file out and file in a package, manage them, create new classes save methods, open a workspace which only resolves globals from a particular namespace, and create instances of objects in those namespaces.
Gulik.
Hi!
Hi Göran, all.
On 9/17/07, Göran Krampe goran@krampe.se wrote:
Hi folks!
I just read through Michael van der Gulik's page:
http://gulik.pbwiki.com/Namespaces
Just stumbled over it btw, and I have only read it once and wrote down some notes compared to my own little "venture" in this area:
http://swiki.krampe.se/gohu/32
Which I like to call "Prefixes Improved" perhaps. Anyway, here goes and this is mainly addressed to Michael btw.
Namespace comments:
- I personally think hierarchical namespaces is "too much". I opted for
single level namespaces and still think that is enough.
We already have hierarchical categories in Squeak. For example, "Kernel-Chronology-Tests". I'm making hierarchical namespaces available, but you don't have to nest things more than one level deep if you don't like that style.
Sure, I understand. I *still* would like to stay with a single level. :) My proposal also keeps the "good old global" level (SystemDictionary) in which I would presume most of the standard libraries would still live.
- I personally don't like the "." notation for namespaces, especially
since we already use "." for statement separation. I still think "::" is the best I have seen, although granted - this is a tiny, tiny detail.
Meh. I like the dots; they look tidy. If you can give me a good reason not to use them then I'm happy to change.
A *good* reason? Hehe, not really. I don't recall the details in lexer/parser etc - adding support for $: inside global names was rather simple - I have no idea if it is just as simple with $.
My reasoning behind :: was that it "stands out" in the syntax - you will not accidentally mistake it for something else. The "." is IMHO not at all as clear. For example, what does this code say:
self add: Kernel.Array new: 4
Is it the same as?:
self add: Kernel. Array new: 4
- Imports are done in your code "per Namespace" which is immensely better
than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
- I agree that shared pools theoretically could be replaced with
Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :)
To be honest, I've never really used shared pools, so I don't know much about how they're used. In my conversion (categories->namespaces) code, I turn a shared pool into a sub-namespace of the class they appear in (ooh... that could be a bug...). I haven't tested this yet. For the meanwhile I've left class pools as they are.
- Your Namespaces are linked to a Package scheme, I personally would
like to keep these concepts separate.
(background for people: Package is a subclass of Namespace and forms the root of a namespace hierarchy).
Why is this a bad thing? Could you be more specific?
IMHO a package is a "deployment unit" more than anything else. A namespace on the other hand is a "pool of unique names" that we developers share with each other one way or the other.
I can see a package both using and defining names in several namespaces. And I can see several packages defining names in the same namespace. Thus I don't see the need for making a hard connection between the two concepts.
BUT... I do of course see many good reasons of finding and reasoning about dependencies between packages by simply looking at the global names they define or use. It has always seemed like the obvious "inputs and outputs" of a package and I bet that we could very easily find 90% of all dependencies just by looking at these names.
regards, Göran
On 9/18/07, Göran Krampe goran@krampe.se wrote:
- I personally don't like the "." notation for namespaces, especially
since we already use "." for statement separation. I still think "::"
is
the best I have seen, although granted - this is a tiny, tiny detail.
Meh. I like the dots; they look tidy. If you can give me a good reason
not
to use them then I'm happy to change.
A *good* reason? Hehe, not really. I don't recall the details in lexer/parser etc - adding support for $: inside global names was rather simple - I have no idea if it is just as simple with $.
My reasoning behind :: was that it "stands out" in the syntax - you will not accidentally mistake it for something else. The "." is IMHO not at all as clear. For example, what does this code say:
self add: Kernel.Array new: 4Is it the same as?:
self add: Kernel. Array new: 4
Hmm.
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
Keep in mind that I only expect people to use this syntax when the import list allows ambiguity in the names. Typically, you'd just see:
self add: Array new: 4.
because Kernel has been added to the import list.
What I am a bit concerned about is that I've made the BNF grammar more complex or that I've made it stupid. If a dot/period is followed by whitespace, it terminates the current statement; else it can validly be part of a word or keyword.
The change was this, in pseudo-diff format:
Scanner>>xLetter "Form a word or keyword." | type c | buffer reset. [c _ hereChar asciiValue. + ((type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type == #xDigit]) + or: [(type == #period) and: [(typeTable at: (aheadChar asciiValue)) == #xLetter]]] - (type _ typeTable at: c ifAbsent: [#xLetter]) == #xLetter or: [type == #xDigit]] ... more method code.
- Your Namespaces are linked to a Package scheme, I personally would
like to keep these concepts separate.
(background for people: Package is a subclass of Namespace and forms the root of a namespace hierarchy).
Why is this a bad thing? Could you be more specific?
IMHO a package is a "deployment unit" more than anything else. A namespace on the other hand is a "pool of unique names" that we developers share with each other one way or the other.
I can see a package both using and defining names in several namespaces. And I can see several packages defining names in the same namespace. Thus I don't see the need for making a hard connection between the two concepts.
I see nothing wrong with a deployment unit containing a pool of unique names. In my approach, a package does both use and define names in several namespaces.
What do you mean by several packages defining names in the same namespace? Are you talking about method overrides? Then like I said before, I can't work out how to do this without creating a security issue (I'm planning on Packages containing completely untrusted code which can be securely executed locally).
If you're talking about defining the same class in multiple packages, then why would you do this? If you're talking about having the same Namespace name (e.g "Collections.String") in multiple packages, then my approach handles that fine (note to self: write a test for this!).
BUT... I do of course see many good reasons of finding and reasoning about
dependencies between packages by simply looking at the global names they define or use. It has always seemed like the obvious "inputs and outputs" of a package and I bet that we could very easily find 90% of all dependencies just by looking at these names.
If there's a need, it is quite easy to make a tool that can show all external dependencies of a package. It's currently quite quick to sort through every namespace in a package and see what the dependencies are.
Gulik.
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
On 9/18/07, Bert Freudenberg bert@freudenbergs.de wrote:
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
Vote registered.
For the near future, there's no need to adopt namespaces into the official image. They can be loaded and used alongside standard Squeak objects. In the far future, if the tools are stable and people find it useful then it would be great to have them in the image.
Gulik.
+1 for ::
Even if it is really
self add: (Kernel::Array new: 4).
:)
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Tuesday, September 18, 2007 6:31 AM To: The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
+10000 for:
self add: (Kernel Array new: 4).
This mechanism preseves the elegant foundation of Smalltalk: 'Everyting is an Object, which receives a messages and returns an object'. In this (Dan's ?) solution, the implementation is late bound and can use the same lookup algorithm as used for messages.
The other solutions lack this elegance.
On Dinsdag, 18 September 2007, Ron Teitelbaum wrote:
+1 for ::
Even if it is really
self add: (Kernel::Array new: 4).
:)
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Tuesday, September 18, 2007 6:31 AM To: The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
On Sep 18, 2007, at 15:58 , Brent Pinkney wrote:
+10000 for:
self add: (Kernel Array new: 4).
This mechanism preseves the elegant foundation of Smalltalk: 'Everyting is an Object, which receives a messages and returns an object'. In this (Dan's ?) solution, the implementation is late bound and can use the same lookup algorithm as used for messages.
This is indeed elegant - however, it "hides" the classes from tools, like, if you want to find references to "Kernel Array".
The other solutions lack this elegance.
Well, in Göran's version there simply is a global named #Kernel::Array which I find quite elegant too (if you like TSTTCPW). It's even hardly a "namespace" so much as it is a formalization of prefixes.
- Bert -
On 18/09/2007, Brent Pinkney brent@zamail.co.za wrote:
+10000 for:
self add: (Kernel Array new: 4).
Nice :)
Period has a potential conflict with expression separator, and double-colon could be kept for variadic messages or argument-related stuff (currently, when there is a colon, an argument is not far, so it would be nice to keep this association).
What about underscore, since it's not used elsewhere in the syntax ;-) Kernel_Array looks like an identifier, Kernel _ Array can be a binary message...
This mechanism preseves the elegant foundation of Smalltalk: 'Everyting is an Object, which receives a messages and returns an object'. In this (Dan's ?) solution, the implementation is late bound and can use the same lookup algorithm as used for messages.
The other solutions lack this elegance.
On Dinsdag, 18 September 2007, Ron Teitelbaum wrote:
+1 for ::
Even if it is really
self add: (Kernel::Array new: 4).
:)
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Tuesday, September 18, 2007 6:31 AM To: The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
Damien Pollet a écrit :
On 18/09/2007, Brent Pinkney brent@zamail.co.za wrote:
+10000 for:
self add: (Kernel Array new: 4).
What about underscore, since it's not used elsewhere in the syntax ;-) Kernel_Array looks like an identifier, Kernel _ Array can be a binary message...
probably stupid but what about using uppercases... am I wrong or full uppercase word have no meaning ? self add: (KERNEL Array new:4)
cédrick
On 9/19/07, Damien Pollet damien.pollet@gmail.com wrote:
Period has a potential conflict with expression separator, and double-colon could be kept for variadic messages or argument-related stuff (currently, when there is a colon, an argument is not far, so it would be nice to keep this association).
What about underscore, since it's not used elsewhere in the syntax ;-) Kernel_Array looks like an identifier, Kernel _ Array can be a binary message...
Period works okay if Period followed by whitespace is an expression separator, and period followed by a printable character can be part of a name.
What's a variadic message?
I'm not sure what the status of underscores are. Currently I think they're still a hack for the back-arrow in the squeak image, and from what I hear they are not accepted in Croquet? It is possible to free them up and make people use either a Unicode back-arrow :-) or :=.
Michael.
On 18/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
Period works okay if Period followed by whitespace is an expression separator, and period followed by a printable character can be part of a name.
granted
What's a variadic message?
With unknown number of arguments (e.g. implicitely passing a collection of values). It's not in smalltalk but Ian Piumarta thought of in for Pepsi, and it is a plausible future extension.
I'm not sure what the status of underscores are. Currently I think they're still a hack for the back-arrow in the squeak image, and from what I hear they are not accepted in Croquet? It is possible to free them up and make people use either a Unicode back-arrow :-) or :=.
Well my suggestion was more a joke, knowing that there would be technical problems because _ is not completely eliminated yet. But still, it would be nice to reclaim that character for other purposes.
Isn't underscore used for assignment?
On 9/18/07, Damien Pollet damien.pollet@gmail.com wrote:
On 18/09/2007, Brent Pinkney brent@zamail.co.za wrote:
+10000 for:
self add: (Kernel Array new: 4).
Nice :)
Period has a potential conflict with expression separator, and double-colon could be kept for variadic messages or argument-related stuff (currently, when there is a colon, an argument is not far, so it would be nice to keep this association).
What about underscore, since it's not used elsewhere in the syntax ;-) Kernel_Array looks like an identifier, Kernel _ Array can be a binary message...
+1000000! Down with the hideous :: :)
On 9/18/07, Brent Pinkney brent@zamail.co.za wrote:
+10000 for:
self add: (Kernel Array new: 4).
This mechanism preseves the elegant foundation of Smalltalk: 'Everyting is an Object, which receives a messages and returns an object'. In this (Dan's ?) solution, the implementation is late bound and can use the same lookup algorithm as used for messages.
The other solutions lack this elegance.
On Dinsdag, 18 September 2007, Ron Teitelbaum wrote:
+1 for ::
Even if it is really
self add: (Kernel::Array new: 4).
:)
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Tuesday, September 18, 2007 6:31 AM To: The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
Array is a class, not a message. This is /not/ elegant and simply doesn't make sense. This is my last comment on this approach.
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Michael.
On 9/19/07, Brent Pinkney brent@zamail.co.za wrote:
+10000 for:
self add: (Kernel Array new: 4).
This mechanism preseves the elegant foundation of Smalltalk: 'Everyting is an Object, which receives a messages and returns an object'. In this (Dan's ?) solution, the implementation is late bound and can use the same lookup algorithm as used for messages.
The other solutions lack this elegance.
On Dinsdag, 18 September 2007, Ron Teitelbaum wrote:
+1 for ::
Even if it is really
self add: (Kernel::Array new: 4).
:)
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:
squeak-dev-
bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Tuesday, September 18, 2007 6:31 AM To: The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
Array is a class, not a message. This is /not/ elegant and simply doesn't make sense. This is my last comment on this approach.
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
Michael.
On 9/19/07, Brent Pinkney brent@zamail.co.za wrote:
+10000 for:
self add: (Kernel Array new: 4).
This mechanism preseves the elegant foundation of Smalltalk: 'Everyting is
an Object, which receives a messages and returns an object'.
In this (Dan's ?) solution, the implementation is late bound and can use
the same lookup algorithm as used for messages.
The other solutions lack this elegance.
On Dinsdag, 18 September 2007, Ron Teitelbaum wrote:
+1 for ::
Even if it is really
self add: (Kernel::Array new: 4).
:)
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org
[mailto: squeak-dev-
bounces@lists.squeakfoundation.org] On Behalf Of Bert
Freudenberg
Sent: Tuesday, September 18, 2007 6:31 AM To: The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
On 9/19/07, Igor Stasenko siguctua@gmail.com wrote:
On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
Array is a class, not a message. This is /not/ elegant and simply
doesn't
make sense. This is my last comment on this approach.
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
Unfortunately, this is important to discuss. It does end up becoming a bike-shed discussion, but in about five years time when most programmers in the world will be using Squeak, the namespacing syntax they use will be the result of this discussion.
I'm still undecided as to which syntax to use and open to suggestions. I'll give it a week or so.
Michael.
On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
On 9/19/07, Igor Stasenko siguctua@gmail.com wrote:
On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
Array is a class, not a message. This is /not/ elegant and simply
doesn't
make sense. This is my last comment on this approach.
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
Unfortunately, this is important to discuss. It does end up becoming a bike-shed discussion, but in about five years time when most programmers in the world will be using Squeak, the namespacing syntax they use will be the result of this discussion.
I'm still undecided as to which syntax to use and open to suggestions. I'll give it a week or so.
Before we having a working namespaces system with working tools, we cannot get a taste of it, and therefore there's nothing to discuss about syntax of namespaces. Just release a code with any syntax you like and just note that It can be subject of change. Syntax is inferior to design. Changing syntax is a 10 minutes task, but changing system behavior to work with namespaces is not so straightforward. So, at first place we should discuss the design, which is most important thing.
As for me, i see nothing 'groundbreaking' in removing global namespace (which is system dictionary). I see nothing awful in having classes with same names in system, since they rooted in different categories (named packages/namespaces or something else) there's no way how you can get confused with ambiguousness. For example in package #Zoo , you can see a class #Duck and you know that its a duck :) and in package #Man-Moves, a class #Duck is something else. I see no ways how this can lead to ambiguousness and confusion. Everyone living with methods which have same selector, but doing different things for different classes. How making classes with same names, but doing different things can be considered awful and inappropriate?
So, i insist, that before saying 'no way, i never accept that', better give it a try and see how changes complicate or simplify development process.
Michael.
Hi!
Before we having a working namespaces system with working tools, we cannot get a taste of it, and therefore there's nothing to discuss about syntax of namespaces.
Mine is available on SM, I think Michaels is also available to taste.
Just release a code with any syntax you like and just note that It can be subject of change. Syntax is inferior to design. Changing syntax is a 10 minutes task, but changing system behavior to work with namespaces is not so straightforward. So, at first place we should discuss the design, which is most important thing.
I agree. :)
As for me, i see nothing 'groundbreaking' in removing global namespace (which is system dictionary).
My proposal does not remove it btw.
I see nothing awful in having classes with same names in system, since they rooted in different categories (named packages/namespaces or something else) there's no way how you can get confused with ambiguousness. For example in package #Zoo , you can see a class #Duck and you know that its a duck :) and in package #Man-Moves, a class #Duck is something else. I see no ways how this can lead to ambiguousness and confusion.
Well, in many cases you are right. But in some cases it can get confusing. Take a class named "Component" or "Manager" or "Date". But this goes to the core of my idea, I want collisions to be "visible" but "handled" instead of hidden away.
In a classical conventional approach you create a sandbox and put your classes there. You can then create Seaside::TcpService and use it and don't even notice you actually created a short name that is colliding with another namespace (let's imagine KomServices had a Namespace too).
In my proposal these collisions are made visible in the sense that if a lot of people use BOTH KomServices and Seaside (which a lot do) then they will notice because even though everything WORKS FINE the references will read out in qualified form and when you type TcpService (in a third other namespace) you will be asked which one you mean.
I am saying this is GOOD because it will "gently guide" ourselves into at least trying to not overloading the same names that other namespaces use. At least those namespaces that tend to be used a lot together - and thus occupy neighboring braincells in developers.
Recall that this is a HUMAN problem, not a technical one. HUMANS have one single shared namespace that we try to keep track of stuff in. If lots and lots of people start reusing the same short name for different things we WILL get confused no matter if the computer is fine with it. :)
Everyone living with methods which have same selector, but doing different things for different classes. How making classes with same names, but doing different things can be considered awful and inappropriate?
Not *awful* but something we should try to keep at a reasonable level and avoid if at all possible. My proposal making short name collisions "visible but handled" is IMHO a mechanism to do that. If we use "pessimistic sandboxes" we invite people to make duplicate short names, IMHO.
So, i insist, that before saying 'no way, i never accept that', better give it a try and see how changes complicate or simplify development process.
Agree.
regards, Göran
On Wed, 19 Sep 2007 01:18:41 -0700, Göran Krampe goran@krampe.se wrote:
Recall that this is a HUMAN problem, not a technical one. HUMANS have one single shared namespace that we try to keep track of stuff in. If lots and lots of people start reusing the same short name for different things we WILL get confused no matter if the computer is fine with it. :)
Oh, no, humans have more namespaces than the most seasoned Java or .NET programmer could imagine, and we usually don't supply the literal context! If I say program, I'll expect you to fill in the right namespace(s).
television.program work.program government.program football.program computer.education.program computer.code.program
(Forgive my use of "." here. Pascal programmers have been using "." since the introduction of "units", which solved both namespace and package problems.)
All that aside, Goran's plan seems to address the problem (and nothing else) with a minimal amount of pain, and has the virtue of being currently usable (I think). It also raises the interesting issue of what problems we should be using tools to solve versus what the language should solve, which I'm not sure gets the proper attention.
Goran, I missed what would happen with existing classes, like "Array". Would existing packages have to be given namespace designations?
===Blake===
Hi!
On Wed, 19 Sep 2007 01:18:41 -0700, Göran Krampe goran@krampe.se wrote:
Recall that this is a HUMAN problem, not a technical one. HUMANS have one single shared namespace that we try to keep track of stuff in. If lots and lots of people start reusing the same short name for different things we WILL get confused no matter if the computer is fine with it. :)
Oh, no, humans have more namespaces than the most seasoned Java or .NET programmer could imagine, and we usually don't supply the literal context! If I say program, I'll expect you to fill in the right namespace(s).
television.program work.program government.program football.program computer.education.program computer.code.program
(Forgive my use of "." here. Pascal programmers have been using "." since the introduction of "units", which solved both namespace and package problems.)
Well, philosophically I agree - people have "lots of namespaces" but as you also imply - we usually communicate with "short names" and we tend to try to not have multiple meanings of the word "program" WITHIN the same context.
In software engineering we have one meaning of "program", and not three.
All that aside, Goran's plan seems to address the problem (and nothing else) with a minimal amount of pain, and has the virtue of being currently usable (I think).
It should be usable - IIRC there was one or two small problems left to figure out regarding fileouts or something, I don't recall. But AFAICT it is 90% done. If a few of us grabbed it and sat down we should be able to get it flying quickly. OOPSLA comes to mind, I am going there btw.
It also raises the interesting issue of what problems we should be using tools to solve versus what the language should solve, which I'm not sure gets the proper attention.
Goran, I missed what would happen with existing classes, like "Array". Would existing packages have to be given namespace designations?
Nope! In the beginning I was going with the idea of turning "top level categories" into Namespaces (Kernel, Collections, Graphics etc) but someone pointed out to me that... "why?". And that person was IMHO right - there is no real point in doing that AFAICT. Even though it could probably work quite easily - but why bother?
So no, when you install my Namespaces proposal into your image nothing much happens. Your classes are there just like before, there are no Namespace instances around until you start making classes named Blabla::Something and if you don't WANT to you can just continue like before - you can even ignore it totally and use old fashion prefixing. :)
Hopefully then people can start using the new prefixing for new code and hopefully also convert old prefixed code bases to it.
regards, Göran
We can try it out today if we want to. It has been a Squeaksource package forever. Why does everything have to be in the main image before it's "tryable"? We are going to all this trouble (well a couple of people are, but we all claim to want) to remove packages from the Squeak image to let people choose what they want, aren't we? But before we're even done we are already deciding that people wont choose it so it needs to be in the main image. Confusing, no?
On 9/19/07, Igor Stasenko siguctua@gmail.com wrote:
On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
On 9/19/07, Igor Stasenko siguctua@gmail.com wrote:
On 19/09/2007, Michael van der Gulik mikevdg@gmail.com wrote:
Array is a class, not a message. This is /not/ elegant and simply
doesn't
make sense. This is my last comment on this approach.
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
Unfortunately, this is important to discuss. It does end up becoming a bike-shed discussion, but in about five years time when most programmers in the world will be using Squeak, the namespacing syntax they use will be the result of this discussion.
I'm still undecided as to which syntax to use and open to suggestions. I'll give it a week or so.
Before we having a working namespaces system with working tools, we cannot get a taste of it, and therefore there's nothing to discuss about syntax of namespaces. Just release a code with any syntax you like and just note that It can be subject of change. Syntax is inferior to design. Changing syntax is a 10 minutes task, but changing system behavior to work with namespaces is not so straightforward. So, at first place we should discuss the design, which is most important thing.
As for me, i see nothing 'groundbreaking' in removing global namespace (which is system dictionary). I see nothing awful in having classes with same names in system, since they rooted in different categories (named packages/namespaces or something else) there's no way how you can get confused with ambiguousness. For example in package #Zoo , you can see a class #Duck and you know that its a duck :) and in package #Man-Moves, a class #Duck is something else. I see no ways how this can lead to ambiguousness and confusion. Everyone living with methods which have same selector, but doing different things for different classes. How making classes with same names, but doing different things can be considered awful and inappropriate?
So, i insist, that before saying 'no way, i never accept that', better give it a try and see how changes complicate or simplify development process.
Michael.
-- Best regards, Igor Stasenko AKA sig.
On 9/18/07, Igor Stasenko siguctua@gmail.com wrote:
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
How code looks is important. If it wasn't then Java wouldn't be the current most popular language. It's also not going to be easy to switch after the fact from e.g. :: to the message sending style.
On 9/22/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 9/18/07, Igor Stasenko siguctua@gmail.com wrote:
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
How code looks is important. If it wasn't then Java wouldn't be the current most popular language.
ROFL :-D. You can't be serious about that!
Gulik.
Oh no, I'm quite serious. The reason Java gained such market share is because it looks similar to the C/C++ languages people felt more comfortable. The guy who wrote about "the next big language" even says this kind of look is a prerequirement now to success.
On 9/22/07, Michael van der Gulik mikevdg@gmail.com wrote:
On 9/22/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 9/18/07, Igor Stasenko siguctua@gmail.com wrote:
Again, discussion downs not to about how namespaces should behave, but to choosing appropriate and conventional syntax for it. Personally, i don't think its really matters. Please, people, lets focus on more important things, if you don't want to flame this topic, like in previous 'pipe syntax'.
How code looks is important. If it wasn't then Java wouldn't be the current most popular language.
ROFL :-D. You can't be serious about that!
Gulik.
-- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/
Array is a class, not a message. This is /not/ elegant and simply
doesn't make sense. This is my last comment on this approach.
That's not strictly correct. In the given example it is a message: you are simply asking the given namespace to answer the named class, and the only confusing thing about it is the message is capitalized. What if it were written as "Kernel array new:4"? It is already possible to create a capitalized message in Squeak, we just avoid it because it gets confusing. However in the given context I simply applaud Dan's genius and I second that it is a simple and elegant solution. For the more conservative approach I would have no problem with a namespace creating a non-capitalized accessor message for the given class but that could cause other confusions.
Tansel
+10000 for: self add: (Kernel Array new: 4). This mechanism preseves the elegant foundation of Smalltalk: 'Everyting
is an Object, which receives a messages and returns an object'.
In this (Dan's ?) solution, the implementation is late bound and can use
the same lookup algorithm as used for messages .
The other solutions lack this elegance.
more over, could be a syntax rule:
capitalized message: answer (self namespace at: message) non-capitalized: traditional message send.
we could as well write (self Array new: 4)
Tansel a écrit :
Array is a class, not a message. This is /not/ elegant and simply
doesn't make sense. This is my last comment on this approach.
That's not strictly correct. In the given example it is a message: you are simply asking the given namespace to answer the named class, and the only confusing thing about it is the message is capitalized. What if it were written as "Kernel array new:4"? It is already possible to create a capitalized message in Squeak, we just avoid it because it gets confusing. However in the given context I simply applaud Dan's genius and I second that it is a simple and elegant solution. For the more conservative approach I would have no problem with a namespace creating a non-capitalized accessor message for the given class but that could cause other confusions.
Tansel
+10000 for: self add: (Kernel Array new: 4). This mechanism preseves the elegant foundation of Smalltalk:
'Everyting is an Object, which receives a messages and returns an object'.
In this (Dan's ?) solution, the implementation is late bound and can
use the same lookup algorithm as used for messages .
The other solutions lack this elegance.
On 19/09/2007, nicolas cellier ncellier@ifrance.com wrote:
more over, could be a syntax rule:
capitalized message: answer (self namespace at: message) non-capitalized: traditional message send.
we could as well write (self Array new: 4)
Well, we don't need to change anything to use lately bound names/classes. You can always introduce messages in your classes, like #myArrayClass #myPointClass e.t.c.
Tansel a écrit :
Array is a class, not a message. This is /not/ elegant and simply
doesn't make sense. This is my last comment on this approach.
That's not strictly correct. In the given example it is a message: you are simply asking the given namespace to answer the named class, and the only confusing thing about it is the message is capitalized. What if it were written as "Kernel array new:4"? It is already possible to create a capitalized message in Squeak, we just avoid it because it gets confusing. However in the given context I simply applaud Dan's genius and I second that it is a simple and elegant solution. For the more conservative approach I would have no problem with a namespace creating a non-capitalized accessor message for the given class but that could cause other confusions.
Tansel
+10000 for: self add: (Kernel Array new: 4). This mechanism preseves the elegant foundation of Smalltalk:
'Everyting is an Object, which receives a messages and returns an object'.
In this (Dan's ?) solution, the implementation is late bound and can
use the same lookup algorithm as used for messages .
The other solutions lack this elegance.
With st/x I used to struggle with dependencies between packages which included references to globals/classes. To avoid any such early bound references I used to define a class called CLASS which you could use as
CLASS Array CLASS String
as a short hand for Smalltalk at: #Array etc. This worked very well for me.
so thinking out load if my CLASS behaviour could be added to Class so that
Class WASession -> WASession
and we define WA similarly, then
WA Session -> WASession
If we make WA the current 'in' namespace, then Class could take that into account, so that
Class Session -> WASession
for tool support, each prefixed class would need to know its prefix.namespace so that tools could show the class name in browsers without the prefix.
WASession-namespace
^WA
its late....
Keith
+10000 for: self add: (Kernel Array new: 4). This mechanism preseves the elegant foundation of Smalltalk:
'Everyting is an Object, which receives a messages and returns an object'.
In this (Dan's ?) solution, the implementation is late bound and
can use the same lookup algorithm as used for messages .
The other solutions lack this elegance.
Hi Keith!
[SNIP]
Class WASession -> WASession
and we define WA similarly, then
WA Session -> WASession
This would be trivial to do right now in my proposal. WA:: is already an object of instance Namespace sitting in Smalltalk so if I add a DNU to it - you got that.
And we could even add a "mapping" mechanism based on sender, like for example, looking at the PI of the sender and decide if we want to resolve in self (WA::) or delegate to another namespace (WA28::).
If we make WA the current 'in' namespace, then Class could take that into account, so that
Class Session -> WASession
I presume the idea here is to do totally "context dependent" resolution, right? First of all, I would probably use Smalltalk instead of Class - we are after all talking about globals and not ONLY classes.
So then you could write:
WA Session
..or:
Smalltalk Session
The first line would mean, give me "Session" in namespace WA:: - and decide yourself what to give me back depending possibly on me as a sender and on any other runtime aspect.
The second line would mean, give me "Session" in whatever namespace is suitable (including the global space) depending possibly on me as a sender and on any other runtime aspect.
for tool support, each prefixed class would need to know its prefix.namespace so that tools could show the class name in browsers without the prefix.
Again, this already works in my proposal though.
In summary, yes, we can have message based simply dynamic lookup that can take runtime context and sender into account. But do we REMOVE all statically bound references and DISALLOW them from now on? That is a *much* larger step IMHO and I can't say I have thought through all ramifications of such a route.
regards, Göran
PS. I can add the above DNUs to my proposal just to show how it can work etc.
On 9/19/07, Paolo Bonzini bonzini@gnu.org wrote:
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Michael.
And what is Array? :-) I understand that you could use "Kernel-#Array" or something similar, but "Kernel/Array" seems hard to get right in the compiler.
Array is a class.... which the Kernel namespace uses to look up.... oh, I see your point.
Okay, bad design :-P.
Gulik.
On Wed, 19 Sep 2007 02:33:19 -0700, Michael van der Gulik mikevdg@gmail.com wrote:
On 9/19/07, Paolo Bonzini bonzini@gnu.org wrote:
What is possible is:
self add: (Kernel-Array new: 4).
Here, #- is a message.
Michael.
And what is Array? :-) I understand that you could use "Kernel-#Array" or something similar, but "Kernel/Array" seems hard to get right in the compiler.
Array is a class.... which the Kernel namespace uses to look up.... oh, I see your point.
Okay, bad design :-P.
I was looking at it more like:
self add: (Kernel-#Array new: 4).
But I guess without the # the namespace object wouldn't see "Array" it would only see an undefined object?
On 9/18/07, Michael van der Gulik mikevdg@gmail.com wrote:
Array is a class, not a message. This is /not/ elegant and simply doesn't make sense. This is my last comment on this approach.
That may be your opinion but if we view a Namespace as an object that gets a message #Array, which causes him to return the object (a meta class) for his idea of Array, then the message concept makes perect sense.
The only difference between this and regular message send is that the "message" is capitalized, but I think this is a nice cue to show that something different is happening here (i.e. resolved at compile time, etc.).
And keep in mind, as with the other proposals, this syntax will only be needed when it is ambiguous without it.
Personally this is the only solution I have seen that I found elegant.
Oh no, are people really so strongly for ::? It make source code look absolutely awful. The period looks a thousand times better, but I don't think there is a non-ambiguous way to do it.
What about message style sytax?
e.g.
self add: (Kernel Array new: 4)
? That looks much better to my eyes, though it does force a trade off: do we find a way of complicating the compiler that the above is resolved at compile time, or do we take the run time lookup hit?
In any event, please don't go with ::, and if you must at least please don't put this in the default image.
On 9/18/07, Ron Teitelbaum Ron@usmedrec.com wrote:
+1 for ::
Even if it is really
self add: (Kernel::Array new: 4).
:)
Ron
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev- bounces@lists.squeakfoundation.org] On Behalf Of Bert Freudenberg Sent: Tuesday, September 18, 2007 6:31 AM To: The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
On Sep 18, 2007, at 11:55 , Michael van der Gulik wrote:
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
+10 for ::
Though I hope this won't become a bikeshed discussion of syntax, but actually result in a Namespace solution getting adopted.
- Bert -
On Sep 18, 2007, at 18:09 , Jason Johnson wrote:
Oh no, are people really so strongly for ::?
I'm rather strongly against ".". And not only because the dot is already too overloaded in Smalltalk.
Dot-notation is becoming ubiquitous in "pop CS" to the point where people don't even admit there are alternatives. In one German state teaching "dot notation" to kids is made mandatory by the school administration, ruling out the use of Smalltalk as a teaching language. I kid you not.
Having it creep into Squeak would make this individual sad. If this means anything to anybody ;)
- Bert -
On 9/18/07, Bert Freudenberg bert@freudenbergs.de wrote:
Oh no, are people really so strongly for ::?
I'm rather strongly against ".". And not only because the dot is already too overloaded in Smalltalk.
Dot-notation is becoming ubiquitous in "pop CS" to the point where people don't even admit there are alternatives. In one German state teaching "dot notation" to kids is made mandatory by the school administration, ruling out the use of Smalltalk as a teaching language. I kid you not.
Having it creep into Squeak would make this individual sad. If this means anything to anybody ;)
- Bert -
Well it does. :) Personally I'm not so sold on '.', I just hate to see <insert barage of hideous languages>'s :: come to Smalltalk as well.
I don't think the dot is an option anyway given the obvious reasons which have already been covered.
What do you think of message syntax for this? I think it could be done at compile time as well, since the compiler is determining the reciever of a message anyway.
On 9/19/07, Bert Freudenberg bert@freudenbergs.de wrote:
On Sep 18, 2007, at 18:09 , Jason Johnson wrote:
Oh no, are people really so strongly for ::?
I'm rather strongly against ".". And not only because the dot is already too overloaded in Smalltalk.
Dot-notation is becoming ubiquitous in "pop CS" to the point where people don't even admit there are alternatives. In one German state teaching "dot notation" to kids is made mandatory by the school administration, ruling out the use of Smalltalk as a teaching language. I kid you not.
Having it creep into Squeak would make this individual sad. If this means anything to anybody ;)
I'm sorry to hear that. If it gets in, I might send you a beer to cheer you up.
Could you explain how the dot is overloaded in Smalltalk? Currently I'm only aware that it's used for ending statements.
The fact that the dot notation (in the context of Namespaces, I assume) is popular is quite important. If it comes only with a small grammatic and typographic cost, then in my opinion it's a good idea to keep things consistent across languages.
What do other Smalltalks use? Could somebody knowledgable give me a quick run-down?
Other programming languages: Python - '.' Java - '.' C++ - '::' C# - '.' Erlang - ':' Haskell - '.' (note 1)
Not a programming language XML - ':' (?) Filesystems - '/', '', ':'.
(1) http://bardolph.ling.ohio-state.edu/cgi-bin/dwww/usr/share/doc/haskell98-rep...
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Jason Johnson Sent: Tuesday, September 18, 2007 9:10 AM To: Ron@usmedrec.com; The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
Oh no, are people really so strongly for ::? It make source code look absolutely awful. The period looks a thousand times better, but I don't think there is a non-ambiguous way to do it.
Maybe you should look at Gorans proposal first. In general, :: would separate the prefix from the class name in such a way that the tools can hide Kernel:: except when there's ambiguity, or in file outs. Formalizing prefixes that we all currently do by convention anyway while keeping the simplicity of a single global namespace and avoiding the need for imports. It's actually a nice proposal and :: doesn't look bad at all, since you'll hardly ever see it.
Ramon Leon
I've looked at the proposal, and you will see it. Today you wouldn't because there are no namespaces and thus no conflicts.
I agree we need namespaces, I just think we can do better, both in looks and in functionality. It's nothing against Goeran, just as I told him, I think his Delta's thing is right on the money. I just think this is really going to "give us only enough rope...."
On 9/18/07, Ramon Leon ramon.leon@allresnet.com wrote:
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of Jason Johnson Sent: Tuesday, September 18, 2007 9:10 AM To: Ron@usmedrec.com; The general-purpose Squeak developers list Subject: Re: Quick comparison of two Namespaces proposals
Oh no, are people really so strongly for ::? It make source code look absolutely awful. The period looks a thousand times better, but I don't think there is a non-ambiguous way to do it.
Maybe you should look at Gorans proposal first. In general, :: would separate the prefix from the class name in such a way that the tools can hide Kernel:: except when there's ambiguity, or in file outs. Formalizing prefixes that we all currently do by convention anyway while keeping the simplicity of a single global namespace and avoiding the need for imports. It's actually a nice proposal and :: doesn't look bad at all, since you'll hardly ever see it.
Ramon Leon
I've looked at the proposal, and you will see it. Today you wouldn't because there are no namespaces and thus no conflicts.
I agree we need namespaces, I just think we can do better,
That's the thing, not everyone agrees about needing them, which in the past has made adding them a losing battle.
both in looks and in functionality. It's nothing against Goeran, just as I told him, I think his Delta's thing is right on the money. I just think this is really going to "give us only enough rope...."
Which is at least a step forward, more than you're likely to get with any other proposal. Watch what a battle adding "real" namespaces turns into, and you'll see how good formalizing prefixes looks after a while.
Ramon Leon
I agree we need namespaces, I just think we can do better,
That's the thing, not everyone agrees about needing them, which in the past has made adding them a losing battle.
+1, and Göran's proposal is transparent and preserves the classic simplicity and dynamism of Smalltalk.
Squeak offers the possibility that "power users" (not hard-core developers), someday, maybe after Squeak By Example showing them how, will "hop in and drive" to sketch a program. But as soon as we require import declarations, etc. just to sling a simple program together, then you've lost the "power users" group and catering exclusively to just programmers and engineers. Not to mention, it feels a bit early bound.
Future Squeaks are moving toward smaller images with less code, where name collisions will be virtually non-existent. In each of these tiny images, will we have a big honkin' namespace system "just in case?" Even in todays phat images, name collisions are the 1% case, so the solution should have the benefit of being invisible 99% of the time, and handling the problem as simply and elegantly as possible that 1% of the time. Göran's approach seems to do this.
- Chris
On 9/19/07, Chris Muller asqueaker@gmail.com wrote:
I agree we need namespaces, I just think we can do better,
That's the thing, not everyone agrees about needing them, which in the
past
has made adding them a losing battle.
+1, and Göran's proposal is transparent and preserves the classic simplicity and dynamism of Smalltalk.
Squeak offers the possibility that "power users" (not hard-core developers), someday, maybe after Squeak By Example showing them how, will "hop in and drive" to sketch a program. But as soon as we require import declarations, etc. just to sling a simple program together, then you've lost the "power users" group and catering exclusively to just programmers and engineers. Not to mention, it feels a bit early bound.
Future Squeaks are moving toward smaller images with less code, where name collisions will be virtually non-existent. In each of these tiny images, will we have a big honkin' namespace system "just in case?" Even in todays phat images, name collisions are the 1% case, so the solution should have the benefit of being invisible 99% of the time, and handling the problem as simply and elegantly as possible that 1% of the time. Göran's approach seems to do this.
Naming collisions aren't my concern.
I want to be able to load untrusted code and run it, securely.
This means that I need a unit for loading remote code, thus the package was born. It also means I need to have complete control over what that remote code has access to. If you give untrusted code access to the global SystemDictionary, it has access to everything (which I consider bad practice). To solve this, I've been working on a design for Namespaces that lets a code loader show a certain amount of discretion about what a package has access to (i.e. the import lists).
Answering your points directly, I'm hoping that my tools will not be that difficult to use so that even power users can use them. The import lists should usually be automatically populated by the NamespaceBrowser.
As with smaller images, naming collisions only require two loaded packages to happen (even on the smallest image), and I'd find it pretty damn annoying if they happen for 1% of all class names. That's every third or fourth package.
Gulik.
Are the classes aware of their namespace? In which case, your security might be broken
AnyPublicClass namespace class allInstances detect: [:e | e name = #Smalltalk].
Anyway, no need for namespace at all, just a:
(AnyPublicClass withAllSuperclasses last allSubclasses detect: [:e | e name = #SystemDictionary]) allInstances etc...
Sorry, you might have to restrict available messages too...
Michael van der Gulik a écrit :
Naming collisions aren't my concern.
I want to be able to load untrusted code and run it, securely.
This means that I need a unit for loading remote code, thus the package was born. It also means I need to have complete control over what that remote code has access to. If you give untrusted code access to the global SystemDictionary, it has access to everything (which I consider bad practice). To solve this, I've been working on a design for Namespaces that lets a code loader show a certain amount of discretion about what a package has access to ( i.e. the import lists).
Answering your points directly, I'm hoping that my tools will not be that difficult to use so that even power users can use them. The import lists should usually be automatically populated by the NamespaceBrowser.
As with smaller images, naming collisions only require two loaded packages to happen (even on the smallest image), and I'd find it pretty damn annoying if they happen for 1% of all class names. That's every third or fourth package.
Gulik.
On 9/20/07, nicolas cellier ncellier@ifrance.com wrote:
Are the classes aware of their namespace? In which case, your security might be broken
AnyPublicClass namespace class allInstances detect: [:e | e name = #Smalltalk].
Anyway, no need for namespace at all, just a:
(AnyPublicClass withAllSuperclasses last allSubclasses detect: [:e | e name = #SystemDictionary]) allInstances etc...
Sorry, you might have to restrict available messages too...
Yes, classes are aware of their namespaces, and I'll need to find a way to solve this problem. It's a challenge but not technically infeasible.
Refererences: http://gulik.pbwiki.com/SecureSqueak http://wiki.squeak.org/squeak/uploads/2074/sandbox.html
Gulik.
Hi Chris,
Even in todays phat images, name collisions are the 1% case, so the solution should have the benefit of being invisible 99% of the time, and handling the problem as simply and elegantly as possible that 1% of the time. Göran's approach seems to do this.
You could argue that for most of the constructs in the image.
Almost all classes use the default Metaclass hierarchy. Should we remove those? Almost all classes are pretty shallow subclasses of Object: Should we limit the image to a depth of 3 or 4?
What is requires is a really eleganct unconstrined solution which is transparent for 99% of the cases but entirely open to modifications for the 1%. The Metaclass implementation is a good example of how this can be done. Göran's solution does not satisfy these criteria.
Examples: 1. VisualAge's decision to use C-syle call stacks instead of proper objects prevented the use of continuations. This platform cannot not foster innovations like Seaside. 2. Squeak needs proper BlockClosures: sure BlockContexts suffice for 99% of the time, but they are not the timeless solution. 3. MetaclassTalk
You are correct that the solution must be transparent in 99% of the cases.
Cheers
Brent
Hi!
Hi Chris,
Even in todays phat images, name collisions are the 1% case, so the solution should have the benefit of being invisible 99% of the time, and handling the problem as simply and elegantly as possible that 1% of the time. Göran's approach seems to do this.
You could argue that for most of the constructs in the image.
Almost all classes use the default Metaclass hierarchy. Should we remove those? Almost all classes are pretty shallow subclasses of Object: Should we limit the image to a depth of 3 or 4?
What is requires is a really eleganct unconstrined solution which is transparent for 99% of the cases but entirely open to modifications for the 1%. The Metaclass implementation is a good example of how this can be done. Göran's solution does not satisfy these criteria.
Please elaborate the criteria you mention.
regards, Göran
Brent Pinkney wrote:
- VisualAge's decision to use C-syle call stacks instead of proper
objects prevented the use of continuations.
Just to nitpick, continuations can be perfectly well implemented even in C (I have done so before, using setjmp/longjmp and stack copying, based on a technique I saw used in Aubrey Jaffer's SCM interpreter), so it seems to me that the problem is perhaps more one of a lack of complete *reflective access* to the C-style stack than anything to do with the implementation in the VM itself.
Of course, I haven't investigated VisualAge for myself, so I could well be off base here.
Regards, Tony
Well, this adds levels of complexity to VM, by adding hard tricks, like controlling C heap allocations (not VM heap, controlled by GC).
On 23/09/2007, Tony Garnock-Jones tonyg@lshift.net wrote:
Brent Pinkney wrote:
- VisualAge's decision to use C-syle call stacks instead of proper
objects prevented the use of continuations.
Just to nitpick, continuations can be perfectly well implemented even in C (I have done so before, using setjmp/longjmp and stack copying, based on a technique I saw used in Aubrey Jaffer's SCM interpreter), so it seems to me that the problem is perhaps more one of a lack of complete *reflective access* to the C-style stack than anything to do with the implementation in the VM itself.
Of course, I haven't investigated VisualAge for myself, so I could well be off base here.
Regards, Tony
On 18/09/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
What about message style sytax?
e.g.
self add: (Kernel Array new: 4)
This looks like how GNU Smalltalk handles namespaces. Following up the references in the gst info files, I found some discussion on the Squeak wiki which includes some work done by Augustin Mrazik in 1992:
On 9/19/07, Michael Davies mykdavies+squeak@gmail.com wrote:
On 18/09/2007, Jason Johnson jason.johnson.081@gmail.com wrote:
What about message style sytax?
e.g.
self add: (Kernel Array new: 4)
This looks like how GNU Smalltalk handles namespaces. Following up the references in the gst info files, I found some discussion on the Squeak wiki which includes some work done by Augustin Mrazik in 1992:
Thanks... this is a really good find. Reading.
Gulik.
self add: (Kernel Array new: 4)
This looks like how GNU Smalltalk handles namespaces. Following up the references in the gst info files, I found some discussion on the Squeak wiki which includes some work done by Augustin Mrazik in 1992:
GNU Smalltalk supports both "Kernel Array" and "Kernel.Array". The former is late (run-time) bound, the latter is compile-time bound using the same old "store an association in the method" technique as Squeak.
Paolo
Hi,
What I am a bit concerned about is that I've made the BNF grammar more complex or that I've made it stupid. If a dot/period is followed by whitespace, it terminates >>the current statement; else it can validly be part of a word or keyword.
Your changes allow the following method to be compiled ... x.y ^42
and then ... 1 x.y. evaluates to 42, which is probably not what you intended
Cheers, Andy
On 9/18/07, Andrew Tween amtween@hotmail.com wrote:
Hi,
What I am a bit concerned about is that I've made the BNF grammar more complex or that I've made it stupid. If a dot/period is followed by whitespace, it terminates >>the current statement; else it can validly
be
part of a word or keyword.
Your changes allow the following method to be compiled ... x.y ^42
and then ... 1 x.y. evaluates to 42, which is probably not what you intended
Argh. I saw that too when I cut and paste.
Thanks for pointing it out.
Gulik.
On 9/18/07, Michael van der Gulik mikevdg@gmail.com wrote:
What do you mean by several packages defining names in the same namespace?
He means: Namespace - a collection of symbols inside a space, Package - A group of symbols, etc. that form some kind of deployment unit via MC, etc.
Hi!
"Michael van der Gulik" mikevdg@gmail.com wrote:
On 9/18/07, G=F6ran Krampe goran@krampe.se wrote:
- I personally don't like the "." notation for namespaces, especially
since we already use "." for statement separation. I still think "::"
is
the best I have seen, although granted - this is a tiny, tiny detail.
Meh. I like the dots; they look tidy. If you can give me a good reason
not
to use them then I'm happy to change.
A *good* reason? Hehe, not really. I don't recall the details in lexer/parser etc - adding support for $: inside global names was rather simple - I have no idea if it is just as simple with $.
My reasoning behind :: was that it "stands out" in the syntax - you will not accidentally mistake it for something else. The "." is IMHO not at al=
l
as clear. For example, what does this code say:
self add: Kernel.Array new: 4Is it the same as?:
self add: Kernel. Array new: 4Hmm.
self add: Kernel.Array new: 4. self add: Kernel::Array new: 4.
What do other people think?
Let me just note that the second version using :: is NOT ambiguous for the parser - the one using "." seems to be unless I am missing something obvious.
Keep in mind that I only expect people to use this syntax when the import list allows ambiguity in the names. Typically, you'd just see:
self add: Array new: 4.
because Kernel has been added to the import list.
Of course, and similarly goes for my proposal - you would very rarely see or type fully qualifieid names there too. But again - I am trying to put my finger on a parsing disambiguity here. :)
What I am a bit concerned about is that I've made the BNF grammar more complex or that I've made it stupid. If a dot/period is followed by whitespace, it terminates the current statement; else it can validly be par= t of a word or keyword.
[SNIP of change]
- Your Namespaces are linked to a Package scheme, I personally would
like to keep these concepts separate.
(background for people: Package is a subclass of Namespace and forms th=
e
root of a namespace hierarchy).
Why is this a bad thing? Could you be more specific?
IMHO a package is a "deployment unit" more than anything else. A namespac=
e
on the other hand is a "pool of unique names" that we developers share with each other one way or the other.
I can see a package both using and defining names in several namespaces. And I can see several packages defining names in the same namespace. Thus I don't see the need for making a hard connection between the two concepts.
I see nothing wrong with a deployment unit containing a pool of unique names. In my approach, a package does both use and define names in several namespaces.
Ok, so one package can define names in several different namespaces? Ehh... that sounds slightly different than what I read - perhaps I misunderstood the relationship between a Package and a Namespace in your solution.
What do you mean by several packages defining names in the same namespace? Are you talking about method overrides? Then like I said before, I can't work out how to do this without creating a security issue (I'm planning on Packages containing completely untrusted code which can be securely execute= d locally).
I am not talking about method overrides, no. I am simply talking about package P1 defining a class X in N1 and package P2 defining class Y in N1. Nothing magical. :)
But I think you wrote that Package is actually a subclass of Namespace so perhaps your mental model of package == namespace is making this sound *crazy*. :) But I still think these two concepts are orthogonal - even though often we (developers on planet earth) *decide* that one should be tightly bound to the other.
I see value in NOT making that tie, for once.
If you're talking about defining the same class in multiple packages, then
No, I am not. :)
regards, Göran
On 9/19/07, goran@krampe.se goran@krampe.se wrote:
Hi!
Hello :-).
"Michael van der Gulik" mikevdg@gmail.com wrote:
What do you mean by several packages defining names in the same
namespace?
Are you talking about method overrides? Then like I said before, I can't work out how to do this without creating a security issue (I'm planning
on
Packages containing completely untrusted code which can be securely
execute=
d locally).
I am not talking about method overrides, no. I am simply talking about package P1 defining a class X in N1 and package P2 defining class Y in N1. Nothing magical. :)
My implementation handles this fine. In this case, you'd have P1 containing N1::X (using Krampe notation) and P2 containing N1::Y. The import list of your code using X and Y would include P1 and P2 (import lists contain only other Namespaces, and Packages are Namespaces).
When your code contains the name "N1::X", then the compiler will search P1 (from the import list) for N1, then that N1 for X and find it (and continue searching to make sure the name isn't ambiguous). When your code contains the name "N2::X" then the compiler will search P1 (from the import list) for N1, search that N1 for Y, not find it, search P2 (from the import list) for N1, search that N1 for Y, find it and return it (and continue searching to make sure it isn't ambiguous).
Michael.
Hi!
On 9/19/07, goran@krampe.se goran@krampe.se wrote:
"Michael van der Gulik" mikevdg@gmail.com wrote:
What do you mean by several packages defining names in the same
namespace?
Are you talking about method overrides? Then like I said before, I
can't
work out how to do this without creating a security issue (I'm
planning on
Packages containing completely untrusted code which can be securely
execute=
d locally).
I am not talking about method overrides, no. I am simply talking about package P1 defining a class X in N1 and package P2 defining class Y in N1. Nothing magical. :)
My implementation handles this fine. In this case, you'd have P1 containing N1::X (using Krampe notation) and P2 containing N1::Y. The import list of your code using X and Y would include P1 and P2 (import lists contain only other Namespaces, and Packages are Namespaces).
If I understand you correctly (there are lots of assumptions here that I am not totally getting) - you are saying:
- Package IS a Namespace. - Two packages CAN define names in the same namespace.
I may be daft but I don't get it. So P1 "contains" N1 and so does P2? And a package IS a Namespace? So N1 can appear in multiple places in your hierarchy, is that what you mean?
regards, Göran
On 9/19/07, Göran Krampe goran@krampe.se wrote:
Hi!
On 9/19/07, goran@krampe.se goran@krampe.se wrote:
"Michael van der Gulik" mikevdg@gmail.com wrote:
What do you mean by several packages defining names in the same
namespace?
Are you talking about method overrides? Then like I said before, I
can't
work out how to do this without creating a security issue (I'm
planning on
Packages containing completely untrusted code which can be securely
execute=
d locally).
I am not talking about method overrides, no. I am simply talking about package P1 defining a class X in N1 and package P2 defining class Y in N1. Nothing magical. :)
My implementation handles this fine. In this case, you'd have P1 containing N1::X (using Krampe notation) and P2 containing N1::Y. The import list
of
your code using X and Y would include P1 and P2 (import lists contain
only
other Namespaces, and Packages are Namespaces).
If I understand you correctly (there are lots of assumptions here that I am not totally getting) - you are saying:
- Package IS a Namespace.
- Two packages CAN define names in the same namespace.
I may be daft but I don't get it. So P1 "contains" N1 and so does P2? And a package IS a Namespace? So N1 can appear in multiple places in your hierarchy, is that what you mean?
Well... kind of. I'll explain it in code:
Package is a subclass of Namespace; Namespace is a subclass of Dictionary.
p1 := Package new. n1 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n1. " should be p1 addNamespace: n1. " n1 at: #X put: X.
p2 := Package new. n2 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n2. n2 at: #Y put: Y.
Now, if you add both p1 and p2 to your local import list, you can refer to Namespace1.X and Namespace1.Y.
Does this answer your question?
Regards, Gulik.
Hi Michael!
If I understand you correctly (there are lots of assumptions here that I am not totally getting) - you are saying:
- Package IS a Namespace.
- Two packages CAN define names in the same namespace.
I may be daft but I don't get it. So P1 "contains" N1 and so does P2? And a package IS a Namespace? So N1 can appear in multiple places in your hierarchy, is that what you mean?
Well... kind of. I'll explain it in code:
Package is a subclass of Namespace; Namespace is a subclass of Dictionary.
p1 := Package new. n1 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n1. " should be p1 addNamespace: n1. " n1 at: #X put: X.
p2 := Package new. n2 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n2. n2 at: #Y put: Y.
Now, if you add both p1 and p2 to your local import list, you can refer to Namespace1.X and Namespace1.Y.
Does this answer your question?
Ehm, well. :) It looks like a Package can contain any namespaces (like for example one that you already have with the same name in another package) and that the complete "tree" of the namespaces is the merged tree of all packages in your image? But then I have a hard time seeing that a Package ISA Namespace (subclass). Or perhaps the Namespace tree is in fact not a tree at all.
And even if I am wrong... this feels complicated to me. But then again I am pretty daft. ;)
regards, Göran
On 9/20/07, Göran Krampe goran@krampe.se wrote:
Hi Michael!
If I understand you correctly (there are lots of assumptions here that
I
am not totally getting) - you are saying:
- Package IS a Namespace.
- Two packages CAN define names in the same namespace.
I may be daft but I don't get it. So P1 "contains" N1 and so does P2? And a package IS a Namespace? So N1 can appear in multiple places in your hierarchy, is that what you mean?
Well... kind of. I'll explain it in code:
Package is a subclass of Namespace; Namespace is a subclass of
Dictionary.
p1 := Package new. n1 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n1. " should be p1 addNamespace: n1. " n1 at: #X put: X.
p2 := Package new. n2 := Namespace new name: #Namespace1. p1 at: #Namespace1 put: n2. n2 at: #Y put: Y.
Now, if you add both p1 and p2 to your local import list, you can refer
to
Namespace1.X and Namespace1.Y.
Does this answer your question?
Ehm, well. :) It looks like a Package can contain any namespaces (like for example one that you already have with the same name in another package) and that the complete "tree" of the namespaces is the merged tree of all packages in your image? But then I have a hard time seeing that a Package ISA Namespace (subclass). Or perhaps the Namespace tree is in fact not a tree at all.
And even if I am wrong... this feels complicated to me.
Yea, it's pretty complicated. I spent ages contriving up the design, but the results are pretty spectacular and allow for some pretty nifty tricks.
I've edited http://gulik.pbwiki.com/Namespaces. Let me know if this is easier to understand.
Packages sub-class from Namespaces so that they can contain Namespaces in the same way that Namespaces contain other Namespaces. It also means they can be validly added to import lists.
My namespaces are not all merged together, because the compiler does not search every package/namespace instance in the image. The compiler /only/ searches a method's local Namespace instance, and then it searches that local Namespace's import list. It does not search anywhere else. If the name is not found in the local Namespace instance or in the import list, the code will not compile. To make use of a name, you need to add the namespace object containing that name to the local namespace's import list.
Gulik.
Let me just note that the second version using :: is NOT ambiguous for the parser - the one using "." seems to be unless I am missing something obvious.
You have to treat ". with an alphabetic lookahead" as a different kind of token (that would be "."/[A-Za-z] in Flex). Then there is no ambiguity anymore.
What I am a bit concerned about is that I've made the BNF grammar more complex or that I've made it stupid. If a dot/period is followed by whitespace, it terminates the current statement; else it can validly be part of a word or keyword.
The BNF is not more complex if you move the distinction up to the lexical analyzer.
Paolo
Hi
- I personally don't like the "." notation for namespaces, especially
since we already use "." for statement separation. I still think "::" is the best I have seen, although granted - this is a tiny, tiny detail.
Meh. I like the dots; they look tidy. If you can give me a good reason not to use them then I'm happy to change.
A *good* reason? Hehe, not really. I don't recall the details in lexer/parser etc - adding support for $: inside global names was rather simple - I have no idea if it is just as simple with $.
My reasoning behind :: was that it "stands out" in the syntax - you will not accidentally mistake it for something else. The "." is IMHO not at all as clear. For example, what does this code say:
And its known from the ruby language. I like the :: notation I went from ruby to squeak and I like both.
just my 2 cent Enno
- Imports are done in your code "per Namespace" which is immensely
better than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
the problem with per namespace is that you can get unanticipated conflicts. here is a scenario that klaus from Smalltalk/x explained to me once
you have two namespace
N1 A
N2 import N1 B method foo ^ B
everthing compiles
now you add a new class B in N1 and the system does not bark....
a while later you recompile the method foo and now you may be in trouble.
I only have 2 min for this email so I let you imagine other scenario. But klaus told me that this was a problem in VW and C++ too.
Stef
Hi!
stephane ducasse stephane.ducasse@free.fr wrote:
- Imports are done in your code "per Namespace" which is immensely
better than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
the problem with per namespace is that you can get unanticipated conflicts. here is a scenario that klaus from Smalltalk/x explained to me once
you have two namespace
N1 A
N2 import N1 B method foo ^ B
everthing compiles
now you add a new class B in N1 and the system does not bark....
a while later you recompile the method foo and now you may be in trouble.
Ok, so to explain your use case further - before N1 had a B, the foo method was obviously bound to the B in N2 - because there was no other B. Then you added another B to N1 and then recompile foo and now there are two B-choices - the local one in N2 or the imported one in N1, right?
In my proposal this is not a problem at all, this is what would happen:
First we have a class named N1::A and a class named N2::B. There is no import (since I don't have that concept at all). When typing in method N2::B>>foo and typing "B" nothing strange or odd will happen - as long as there is no other B around in the image (in any other namespace) Squeak will resolve it to N2::B and the *source* stored in method foo will be:
^ N2::B
...BUT it will *look* like "^ B" in the browsers because the short form is enough - there is no other B around so we render and accept the short form "B".
Now someone creates another B in the image - N1::B. After that we browse foo and it still renders in short form. How is that? Well, if the reference would have been to a class in ANOTHER namespace (non local) then it suddenly would render like "^ N2::B" because the short form is no longer "enough". So there is a policy to accept and render short forms even if there are multiple Bs *if* the reference is LOCAL - which is the case here.
Anyway, so what if we recompile then? No problem, it is in fact NOTHING different from now. The reference was always FULLY QUALIFIED in the source and thus a recompile is no problem at all.
regards, Göran
On 9/19/07, stephane ducasse stephane.ducasse@free.fr wrote:
the problem with per namespace is that you can get unanticipated conflicts. here is a scenario that klaus from Smalltalk/x explained to me once
you have two namespace
N1 A
N2 import N1 B method foo ^ B
everthing compiles
now you add a new class B in N1 and the system does not bark....
a while later you recompile the method foo and now you may be in trouble.
This is a problem that I'm currently working with. I think I'll try completely disallowing ambiguous names. If a name in a method can resolve to anything other than exactly one binding, then the compiler complains. The user will have to resolve this either by reorganising the local import list, or making the name less ambiguous using either dotted notation or Krampe notation ('::').
Michael.
On 9/17/07, Göran Krampe goran@krampe.se wrote:
- I personally think hierarchical namespaces is "too much". I opted for
single level namespaces and still think that is enough.
But this is a slippery slope. Afterall, flat wasn't enough, why should we think 1 level would be enough forever?
- Imports are done in your code "per Namespace" which is immensely better
than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
Well, the issue I have with your proposal is it isn't really a Namespace/Package proposal, it's simply a proposal to always add your prefixes with a ::, and add some tool support to deal with it.
In my opinion Namespaces are a complicated subject and using such a simple method to deal with them is just sweeping the problem under the rug for someone else.
I try to make my own solutions as simple as possible, but no simpler. Personally, I think that if we need namespaces now there are good examples to follow: Lisp, Python, possibly Haskell all have good Namespace/Package systems we could emulate.
- I agree that shared pools theoretically could be replaced with
Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :)
What is the problem with shared pools? That they're a kind of global variable? I haven't used them much myself, but personally I would prefer a good argument for getting rid of them since the creators of Smalltalk seem to think they were useful.
- Your Namespaces are linked to a Package scheme, I personally would like
to keep these concepts separate.
From Lisp or Python terms "Namespace" and "Package" are synominous. I
think you are talking about Package as in "an MC package", no? That is a package as well, but it's from a different namespace. :) In regards to language I don't think there is much difference between the two except that people tend to call their thing "Namespace" if it's extremely simple (e.g. C++'s solution) and package if it's more complete.
- You go hierarchical, I stayed simple and kept it on one level.
I think this is fundamentally a hierarchical issue.
- You added an explicit import list per Namespace, I opted to not have
imports at all.
For a complete system imports are required unless you want to be typing the whole path out everytime, which is what we have right now (i.e. no need to add a bunch of stuff to just end up where we are now)
Hi!
"Jason Johnson" jason.johnson.081@gmail.com wrote:
On 9/17/07, Göran Krampe goran@krampe.se wrote:
- I personally think hierarchical namespaces is "too much". I opted for
single level namespaces and still think that is enough.
But this is a slippery slope. Afterall, flat wasn't enough, why should we think 1 level would be enough forever?
This reasoning makes no real sense to me. Why would multiple levels be "better"? Are we afraid of running out of namespace names? IMHO the proliferation of namespaces and hierarchies of them in other languages (like Java) is more based on the fact that they are used for organisational purposes.
I don't see the need for that many namespaces - in fact, they should probably map rather well to *communities* or *projects* rather than *packages*. Which again is why I don't consider namespace==package.
To make myself even clearer: The base Smalltalk-80 libraries could all be in one single namespace - and for convenience, let's jus stick to good ole "Smalltalk". The whole Seaside community could use ONE namespace. The Croqueteers could use ONE or a few. We don't need to create a namespace for every little silly class library you know! :)
- Imports are done in your code "per Namespace" which is immensely better
than like for example in Java where it is per class (well, per file, but anyway). It is still though the major difference with my proposal in which there are *no* explicit imports at all.
Well, the issue I have with your proposal is it isn't really a Namespace/Package proposal, it's simply a proposal to always add your prefixes with a ::, and add some tool support to deal with it.
In my opinion Namespaces are a complicated subject and using such a simple method to deal with them is just sweeping the problem under the rug for someone else.
Well, I disagree of course. :) I think most people think it is so complicated because they mix it up with deployment/packaging AND/OR SCM issues.
Just maintaining spaces of unique names isn't rocket science IMHO. And yes, I agree - my proposal is NOT a *Package* proposal - it *is* a Namespace proposal though. Even though calling it "Prefixes improved" might make it sound less threatening. :)
BUT... please give me use cases etc that you think are not handled by my scheme and I will try to answer with how it would work. Like I just did with Stephane's use case.
I try to make my own solutions as simple as possible, but no simpler. Personally, I think that if we need namespaces now there are good examples to follow: Lisp, Python, possibly Haskell all have good Namespace/Package systems we could emulate.
But why? Smalltalk is different. We can always *learn* from other languages but just copying is not good.
- I agree that shared pools theoretically could be replaced with
Namespaces, but then we actually have imports *per class*, which I really don't like. You may argue, "but we already have them!" - yes, I agree, but I don't like them anyway and in my proposal I opted out by simply ignoring/not touching them. :)
What is the problem with shared pools? That they're a kind of global variable? I haven't used them much myself, but personally I would prefer a good argument for getting rid of them since the creators of Smalltalk seem to think they were useful.
I would like to hear the views from the creators in this case. Just the fact that they are very seldomly used should IMHO signal us to reconsider. They are a namespace imported per class. They do create an "environment" where code behaves differently and where you can easily "trick" the reader - like having a shared pool shadowing a global etc.
IMHO a mechanism that widens the gap between what you read and type and what is actually executed - is generally a problem. Imports in general is such a problem, especially imports per class and in which ordering of imports matter (just mention the word "class path" to a java developer and watch him/her squirm).
Also - the fact that a shared pool does not even have to be a global, well, it sure makes them "tricksy enough" to warrant some scrutiny IMHO.
- Your Namespaces are linked to a Package scheme, I personally would like
to keep these concepts separate.
From Lisp or Python terms "Namespace" and "Package" are synominous. I think you are talking about Package as in "an MC package", no? That is a package as well, but it's from a different namespace. :) In regards to language I don't think there is much difference between the two except that people tend to call their thing "Namespace" if it's extremely simple (e.g. C++'s solution) and package if it's more complete.
I know that most languages mix these concepts - but that doesn't make it mystically right. :) Most code packages (as in deployment unit - think class library for example) are developed by individuals or groups of developers and it is convenient to create a little "sandbox" in which that group can maintain their own names without having to risk collisions with the rest of the world. This is what I call "pessimistic approach" - as in, you "lock" your own space and that's it. Downsides are proliferation of lots of small namespaces "just in case" and duplicated classes - lots of Date classes for example (see java again).
I am proposing fewer namespaces that are "more shared" and instead "embrace collisions" by using an optimistic approach and deal with them when they appear. This is what we do today in SystemDictionary when we don't use prefixes - we are in fact maintaining and tending a shared namespace (hundreds of developers) and sometimes we end up with collisions and then we deal with that. This is GOOD. Putting every little silly class in its own little space - like for example if we equal class category to namespace - that would be nuts.
- You go hierarchical, I stayed simple and kept it on one level.
I think this is fundamentally a hierarchical issue.
I am very curious to why you think so. Even in java the hierarchy is just by convention. I definitely do not see any obvious reason to why namespaces should have a father-child relation and I definitely don't see any obvious interpretation of such a relation. Really, I am not trolling. :)
- You added an explicit import list per Namespace, I opted to not have
imports at all.
For a complete system imports are required unless you want to be typing the whole path out everytime, which is what we have right now (i.e. no need to add a bunch of stuff to just end up where we are now)
This last statement shows clearly that you have not read about my proposal in any kind of depth, which of course is fine - it is by all means not required bedtime reading. :) But let me just say that imports is NOT the only way to get rid of fully qualified names in typing and reading.
In my proposal all classes (globals of course, but hey - we are talking about 99% classes) that have unique short names in the image (that would easily be 98% I guess) are always rendered and typed in their short form. ONLY the classes which are duplicates (Fruit::Orange and Color::Orange) would be rendered in fully qualified form and they still only need to be typed shortly - the browser will ask which one you mean and expand upon save.
AND... they would still be accepted in short form and rendered in short form if the reference is LOCAL - for example if code in Fruit::Apple references Orange you only type "Orange" and read "Orange" even though Color::Orange exists. But this is only policy - but I felt it was a nice thing to do.
And no, not a single import in sight! :)
regards, Göran
+1
On 9/18/07, goran@krampe.se goran@krampe.se wrote:
I don't see the need for that many namespaces - in fact, they should probably map rather well to *communities* or *projects* rather than *packages*. Which again is why I don't consider namespace==package.
On 9/18/07, goran@krampe.se goran@krampe.se wrote:
This reasoning makes no real sense to me. Why would multiple levels be "better"? Are we afraid of running out of namespace names? IMHO the proliferation of namespaces and hierarchies of them in other languages (like Java) is more based on the fact that they are used for organisational purposes.
Well my reasoning is simple: we have effectively a flat namespace now, and it doesn't seem to be enough. If we add just one more level then we increase our scale by quite a bit but you still have the siltation like:
Net::Socket NetFtp::Socket NetTelnet::Socket
When what you want to say is:
Net::Socket Net::Ftp::Socket Net::Telnet::Socket
In other words, with only one level the Namespaces end up having the same "prepending prefixes" problem as classes have now.
I don't see the need for that many namespaces - in fact, they should probably map rather well to *communities* or *projects* rather than *packages*. Which again is why I don't consider namespace==package.
But don't communities have sub communities? And projects sub projects?
To make myself even clearer: The base Smalltalk-80 libraries could all be in one single namespace - and for convenience, let's jus stick to good ole "Smalltalk". The whole Seaside community could use ONE namespace. The Croqueteers could use ONE or a few. We don't need to create a namespace for every little silly class library you know! :)
We don't but we already do after a fasion. The issue isn't that we want big complicated Java libraries, the issue is that we want the simplest name for our class but it's either taken or likely to clash with something.
Just maintaining spaces of unique names isn't rocket science IMHO. And yes, I agree - my proposal is NOT a *Package* proposal - it *is* a Namespace proposal though. Even though calling it "Prefixes improved" might make it sound less threatening. :)
Well, the terminology is confusing here. Your proposal is what C++ calls "namespaces". In C++ a "namespace" is just a string you prepend to all classes/functions/variables/etc. that are in that "namespace" and the compiler has special help so that you don't have to type it all the time.
In my opinion this was just the simplest way to allow contextualizing of variables that Bjärne could come up with. C++'s is mostly complete but as it is only a compile time convenience there is no possibility of reflection, etc.
But why? Smalltalk is different. We can always *learn* from other languages but just copying is not good.
Agreed. I will make my proposal in a different message. I would like to hear the views from the creators in this case. Just the fact that they are very seldomly used should IMHO signal us to reconsider. They are a namespace imported per class. They do create an "environment" where code behaves differently and where you can easily "trick" the reader - like having a shared pool shadowing a global etc.
True, in their presence one has to be more careful reading the class definitions, but when we get a real package system we will have the same issue. But honestly the tools can easily point this sort of thing out for us.
IMHO a mechanism that widens the gap between what you read and type and what is actually executed - is generally a problem. Imports in general is such a problem, especially imports per class and in which ordering of imports matter (just mention the word "class path" to a java developer and watch him/her squirm).
But it can be managed obviously. Smalltalk gets a big portion of it's power from the tools, and I think the tools can give us an advantage here again.
Also - the fact that a shared pool does not even have to be a global, well, it sure makes them "tricksy enough" to warrant some scrutiny IMHO.
Scrutiny is welcome, as it helps us avoid "onions in the varnish", but I would like to hear Dan or someone make a statement about them at some point.
I know that most languages mix these concepts - but that doesn't make it mystically right. :) Most code packages (as in deployment unit - think class library for example) are developed by individuals or groups of developers and it is convenient to create a little "sandbox" in which that group can maintain their own names without having to risk collisions with the rest of the world. This is what I call "pessimistic approach" - as in, you "lock" your own space and that's it. Downsides are proliferation of lots of small namespaces "just in case" and duplicated classes - lots of Date classes for example (see java again).
But you will see this anyway, we see it now. Presumably if we had your solution (or any solution), the prefixes we have now would be exchanged for a "namespace". So I know mostly Seaside/Magritte/Pier and from there it's: Seaside - WATask, WAComponent, etc., Magritte - MAComponent, etc., Pier - PRStructure and so on. Most projects *do* have what you're calling a namespace already.
I don't think it's "pessimistic", it's just that we want to use the simplest name we can. In the examples above, it's not a "WAComponent", it's a Component in the context of WA or Seaside.
I am proposing fewer namespaces that are "more shared" and instead "embrace collisions" by using an optimistic approach and deal with them when they appear.
And how will they be dealt with? By making a namespace right? It seems like you try to argue here like "it's ok, let us have them! you wont even notice they're there! They will hardly be used!", but it's not true. People want them to use them and the only thing that will remotely slow them down is the desire for platform compatibility. And I don't know how big a factor that is; I see plenty of { } code.
This is what we do today in SystemDictionary when we don't use prefixes - we are in fact maintaining and tending a shared namespace (hundreds of developers) and sometimes we end up with collisions and then we deal with that. This is GOOD. Putting every little silly class in its own little space - like for example if we equal class category to namespace - that would be nuts.
Well, I agree that class categories serve a different function, but you can't believe we will only have one or two namespaces. You can look at e.g. the dev image right now to get a feel for how many we will have.
I am very curious to why you think so. Even in java the hierarchy is just by convention. I definitely do not see any obvious reason to why namespaces should have a father-child relation and I definitely don't see any obvious interpretation of such a relation. Really, I am not trolling. :)
I would never accuse you of trolling. I don't think of it as "father/son" as much as "in the context of". For example, we have the context of Smalltalk, and currently all our code is within that context. Once we have a namespace solution we can expand the contexts further. It can be that a namespace or context itself is not unique in the context of Smalltalk, but something more specific (can't think of any great examples right now, but a cheesy one might be: Booking means something different in the context of Police then it does TradingSystem).
This last statement shows clearly that you have not read about my proposal in any kind of depth, which of course is fine - it is by all means not required bedtime reading. :) But let me just say that imports is NOT the only way to get rid of fully qualified names in typing and reading.
I don't recall if I have or not, certainly I haven't recently. But I realize you don't have to type the names out unless there is a conflict, but what I'm saying is in 5 years time there *will be* conflicts if you don't have imports.
In my proposal all classes (globals of course, but hey - we are talking about 99% classes) that have unique short names in the image (that would easily be 98% I guess) are always rendered and typed in their short form. ONLY the classes which are duplicates (Fruit::Orange and Color::Orange) would be rendered in fully qualified form and they still only need to be typed shortly - the browser will ask which one you mean and expand upon save.
Ok, so you don't have to type it. :)
On 10/4/07, Jason Johnson jason.johnson.081@gmail.com wrote:
On 9/18/07, goran@krampe.se goran@krampe.se wrote:
This reasoning makes no real sense to me. Why would multiple levels be "better"? Are we afraid of running out of namespace names? IMHO the proliferation of namespaces and hierarchies of them in other languages (like Java) is more based on the fact that they are used for organisational purposes.
Well my reasoning is simple: we have effectively a flat namespace now, and it doesn't seem to be enough. If we add just one more level then we increase our scale by quite a bit but you still have the siltation like:
<snip>
If there was anything important in the rest of your email, could you summarise it for me? I'm not going to read the whole thing.
Gulik.
On 10/4/07, Michael van der Gulik mikevdg@gmail.com wrote:
If there was anything important in the rest of your email, could you summarise it for me? I'm not going to read the whole thing.
Same point as you about name classes just being moved
We already have lots of the proposed kind of "namespaces"
The terminology is confusing
The tools can help us with the complicated solution
1000 points of light
Hi!
Long post - probably not that interesting for most people. :)
On 9/18/07, goran@krampe.se goran@krampe.se wrote:
This reasoning makes no real sense to me. Why would multiple levels be "better"? Are we afraid of running out of namespace names? IMHO the proliferation of namespaces and hierarchies of them in other languages (like Java) is more based on the fact that they are used for organisational purposes.
Well my reasoning is simple: we have effectively a flat namespace now, and it doesn't seem to be enough. If we add just one more level then we increase our scale by quite a bit but you still have the siltation like:
Net::Socket NetFtp::Socket NetTelnet::Socket
When what you want to say is:
Net::Socket Net::Ftp::Socket Net::Telnet::Socket
I would actually not want that, I would want:
Net::Socket Net::FtpSocket Net::TelnetSocket
Ehm, noting of course that the design is bad in the first place - it should not be different subclasses of Sockets at all. But my point is still made - we should not use the word Socket for tons of different things.
Also, noting that I am not advocating splitting base classes into spaces either - so there would not be any Net:: at all.
In other words, with only one level the Namespaces end up having the same "prepending prefixes" problem as classes have now.
I don't think so, you can probably come up with an example - but I think it would be quite rare.
I don't see the need for that many namespaces - in fact, they should probably map rather well to *communities* or *projects* rather than *packages*. Which again is why I don't consider namespace==package.
But don't communities have sub communities? And projects sub projects?
They do, but not that often and it would most probably not need to be represented as a "sub space" if they do. For example, Seaside might be considered a "sub community" of the Squeak community - but we sure don't argue that it should be a "sub namespace of Squeak". Same goes for most projects I suspect - Scriptaculous being a sub project of Seaside? Sure, but it doesn't force us to make it a sub namespace.
To make myself even clearer: The base Smalltalk-80 libraries could all be in one single namespace - and for convenience, let's jus stick to good ole "Smalltalk". The whole Seaside community could use ONE namespace. The Croqueteers could use ONE or a few. We don't need to create a namespace for every little silly class library you know! :)
We don't but we already do after a fasion. The issue isn't that we want big complicated Java libraries, the issue is that we want the simplest name for our class but it's either taken or likely to clash with something.
Actually, I think the biggest reason is that we (we being we who are using prefixes) don't want to "pollute" the global space. And yes, we do want to avoid clashes - but not because it would be terrible but because we currently don't have mechanisms to deal with them.
But my point still stands - we don't *need* a space for every package.
Just maintaining spaces of unique names isn't rocket science IMHO. And yes, I agree - my proposal is NOT a *Package* proposal - it *is* a Namespace proposal though. Even though calling it "Prefixes improved" might make it sound less threatening. :)
Well, the terminology is confusing here. Your proposal is what C++ calls "namespaces". In C++ a "namespace" is just a string you prepend to all classes/functions/variables/etc. that are in that "namespace" and the compiler has special help so that you don't have to type it all the time.
In my opinion this was just the simplest way to allow contextualizing of variables that Bjärne could come up with. C++'s is mostly complete but as it is only a compile time convenience there is no possibility of reflection, etc.
I am not sure I caught the "confusing" part.
But why? Smalltalk is different. We can always *learn* from other languages but just copying is not good.
Agreed. I will make my proposal in a different message. I would like to hear the views from the creators in this case. Just the fact that they are very seldomly used should IMHO signal us to reconsider. They are a namespace imported per class. They do create an "environment" where code behaves differently and where you can easily "trick" the reader - like having a shared pool shadowing a global etc.
True, in their presence one has to be more careful reading the class definitions, but when we get a real package system we will have the same issue. But honestly the tools can easily point this sort of thing out for us.
Just because tools can help us doesn't mean it is a good thing/idea in the first place. IMHO the shared pools in Squeak is an ugly wart. Thank god we only use them very sparingly.
IMHO a mechanism that widens the gap between what you read and type and what is actually executed - is generally a problem. Imports in general is such a problem, especially imports per class and in which ordering of imports matter (just mention the word "class path" to a java developer and watch him/her squirm).
But it can be managed obviously. Smalltalk gets a big portion of it's power from the tools, and I think the tools can give us an advantage here again.
Sure, but again, that doesn't mean they are good per se.
Also - the fact that a shared pool does not even have to be a global, well, it sure makes them "tricksy enough" to warrant some scrutiny IMHO.
Scrutiny is welcome, as it helps us avoid "onions in the varnish", but I would like to hear Dan or someone make a statement about them at some point.
Me too. :) I will meet Dan at OOPSLA later this month and will ask him.
I know that most languages mix these concepts - but that doesn't make it mystically right. :) Most code packages (as in deployment unit - think class library for example) are developed by individuals or groups of developers and it is convenient to create a little "sandbox" in which that group can maintain their own names without having to risk collisions with the rest of the world. This is what I call "pessimistic approach" - as in, you "lock" your own space and that's it. Downsides are proliferation of lots of small namespaces "just in case" and duplicated classes - lots of Date classes for example (see java again).
But you will see this anyway, we see it now. Presumably if we had your solution (or any solution), the prefixes we have now would be exchanged for a "namespace". So I know mostly Seaside/Magritte/Pier and from there it's: Seaside - WATask, WAComponent, etc., Magritte - MAComponent, etc., Pier - PRStructure and so on. Most projects *do* have what you're calling a namespace already.
Yes, but the mechanism is not the same. The tools will never ask you about which "Component" you mean so the conflict of short name will not be apparent and thus the current solution is pessimistic.
I don't think it's "pessimistic", it's just that we want to use the simplest name we can. In the examples above, it's not a "WAComponent", it's a Component in the context of WA or Seaside.
Sure, and we can decide to do that. But not *all* the time, sometimes we hopefully end up making the name more descriptive instead. Like I did in your Socket example.
I am proposing fewer namespaces that are "more shared" and instead "embrace collisions" by using an optimistic approach and deal with them when they appear.
And how will they be dealt with? By making a namespace right?
No, either we decide to live with them (hurts just a teeny bit - reading a fully qualified name instead of a short one *iff* both packages are in your image) or we rename one of them.
It seems like you try to argue here like "it's ok, let us have them! you wont even notice they're there! They will hardly be used!", but it's not true.
I am not saying "They will hardly be used!" - you just said that, not me. But yes, you will not notice them much at all. What I am saying is that I don't think we need *as many* namespaces as for example the java community uses - but I am not saying you shouldn't use them.
People want them to use them and the only thing that will remotely slow them down is the desire for platform compatibility. And I don't know how big a factor that is; I see plenty of { } code.
This is what we do today in SystemDictionary when we don't use prefixes - we are in fact maintaining and tending a shared namespace (hundreds of developers) and sometimes we end up with collisions and then we deal with that. This is GOOD. Putting every little silly class in its own little space - like for example if we equal class category to namespace - that would be nuts.
Well, I agree that class categories serve a different function, but you can't believe we will only have one or two namespaces.
For the base classes I *do* believe that. Because we are already maintaining that namespace together and it is working just fine. I didn't mean for the whole world of Squeak.
You can look at e.g. the dev image right now to get a feel for how many we will have.
I am very curious to why you think so. Even in java the hierarchy is just by convention. I definitely do not see any obvious reason to why namespaces should have a father-child relation and I definitely don't see any obvious interpretation of such a relation. Really, I am not trolling. :)
I would never accuse you of trolling. I don't think of it as "father/son" as much as "in the context of". For example, we have the context of Smalltalk, and currently all our code is within that context. Once we have a namespace solution we can expand the contexts further. It can be that a namespace or context itself is not unique in the context of Smalltalk, but something more specific (can't think of any great examples right now, but a cheesy one might be: Booking means something different in the context of Police then it does TradingSystem).
I still don't see the great need nor the semantics of it. But that's fine, we don't need to agree at all. :)
This last statement shows clearly that you have not read about my proposal in any kind of depth, which of course is fine - it is by all means not required bedtime reading. :) But let me just say that imports is NOT the only way to get rid of fully qualified names in typing and reading.
I don't recall if I have or not, certainly I haven't recently. But I realize you don't have to type the names out unless there is a conflict, but what I'm saying is in 5 years time there *will be* conflicts if you don't have imports.
This is an interesting statement that tries to argue that in 5 years we will have much more libraries and code and that this will linearly increase the number of conflicts. At first sight this seems logical BUT it totally ignores the fact that you only get a naming conflict INSIDE AN IMAGE.
And since the number of libraries and code in a given image is not likely to increase all that much (some yes, but not much) the reasoning fails.
An example, let's say Magritte uses Component and so does Seaside. Sure, they are used a lot together in many images and perhaps my proposal would eventually make one of them to rename Component to something more specific. But if a specialised Open GL library used a class Component it would most likely not be loaded at the same time in that many images so it would NOT cause the users to cheer for a rename. See my point?
In my proposal all classes (globals of course, but hey - we are talking about 99% classes) that have unique short names in the image (that would easily be 98% I guess) are always rendered and typed in their short form. ONLY the classes which are duplicates (Fruit::Orange and Color::Orange) would be rendered in fully qualified form and they still only need to be typed shortly - the browser will ask which one you mean and expand upon save.
Ok, so you don't have to type it. :)
Right. And also - if the references are in the LOCAL space then you don't need to read it NOR even choose one in a menu - it will pick the local one and not ask.
regards, Göran
PS. See my other recent post with a different proposal - just to confuse of course. :) :)
Thinking about your discussion late vs early binding:
If the package loading tools were to support compilation (early binding) based upon the definition of the namespace into which the import is occurring then we could stick with early binding being the default rather than accepting the cost of dnu's etc.
I am thinking here of SystemEditor which compiles the new implementation 'off line' so to speak. If System editor can be connected to the namespace SystemDictionary of choice to perform its magic then this could work well.
...
Thinking out load, I am also wondering whether supplying extension methods as a specialized form of trait could also work.
Keith
On 04/10/2007, Göran Krampe goran@krampe.se wrote:
Hi!
An example, let's say Magritte uses Component and so does Seaside. Sure, they are used a lot together in many images and perhaps my proposal would eventually make one of them to rename Component to something more specific. But if a specialised Open GL library used a class Component it would most likely not be loaded at the same time in that many images so it would NOT cause the users to cheer for a rename. See my point?
But then, someone who worked with Component moved to another image and found that Component here is not a Component there and he needs to keep in mind every time that there are different Components in different images. And then everytime he will see reference to Component, he will keep losing time, checking is that Package deals with Seaside component, or with OpenGL component, or maybe with Foo Component? And, in contrast, having full notation like Seaside::Component (or any other proposed form), he'll never be confused while studiyng/checking code in any image.
Personally, i tend to have one huge big image for my dev purposes. I like to have all in single place, rather than running couple squeaks and maintain number of images and keep remember where they live, what packages they use e.t.c. This is much more convenient - suppose i want to update something, so i need to update only single image once, but having many images i forced to do that many times..
On 10/4/07, Göran Krampe goran@krampe.se wrote:
Hi!
I would actually not want that, I would want:
Net::Socket Net::FtpSocket Net::TelnetSocket
Notice the prefixes?
Ehm, noting of course that the design is bad in the first place - it should not be different subclasses of Sockets at all. But my point is still made - we should not use the word Socket for tons of different things.
It's an example, but something more real will come up soon enough.
In other words, with only one level the Namespaces end up having the same "prepending prefixes" problem as classes have now.
I don't think so, you can probably come up with an example - but I think it would be quite rare.
You just showed me one. :)
Actually, I think the biggest reason is that we (we being we who are using prefixes) don't want to "pollute" the global space. And yes, we do want to avoid clashes - but not because it would be terrible but because we currently don't have mechanisms to deal with them.
And we will still need them with a one bucket namespace system for the same reason. "Smalltalk" just becomes something a bit more narrow, but otherwise it's the same situation.
But my point still stands - we don't *need* a space for every package.
I didn't say we would for *every package*.
I am not sure I caught the "confusing" part.
Because different systems call the concept different things. C++ has something very simple and they call it a "namespace". I think everyone else calls the concept either "package" or "module". This may lead one to conclude that the terms mean how the given languages implement them (e.g. since C++ namespaces are simple and Lisp's packages are complex then namespace must mean something simple and package something complex).
I am not saying "They will hardly be used!" - you just said that, not me.
I didn't say you said it, but that it "seems like", in other words, this is how it sounds to me.
For the base classes I *do* believe that. Because we are already maintaining that namespace together and it is working just fine. I didn't mean for the whole world of Squeak.
As you said yourself, we already effectively have namespaces: prefixes. We are not living together in harmony, we're making namespaces the only way we can. This is what I mean, how can you think we will have one or 2 when we don't today? We have lots.
This is an interesting statement that tries to argue that in 5 years we will have much more libraries and code and that this will linearly increase the number of conflicts. At first sight this seems logical BUT it totally ignores the fact that you only get a naming conflict INSIDE AN IMAGE.
And since the number of libraries and code in a given image is not likely to increase all that much (some yes, but not much) the reasoning fails.
You misunderstand me. I'm not saying in 5 years we will have vastly more libraries. Just the ones we do have converted to namespaces.
Hi!
(this whole post smells of "you say tomato, I say tomato" - but anyway)
"Jason Johnson" jason.johnson.081@gmail.com wrote:
On 10/4/07, Göran Krampe goran@krampe.se wrote:
Hi!
I would actually not want that, I would want:
Net::Socket Net::FtpSocket Net::TelnetSocket
Notice the prefixes?
No, those are IMHO not prefixes (again, the example sucks) - those are different classes with similar names. A counter example: in the Delta code we have lots of classes called BlablaChange. That doesn't mean that Blabla is a prefix - it rather means that the classes are similar - they are all "changes".
Or an even simpler counter example: All subclasses of Morph! Do you really consider all the words before the Morph-suffix to be "prefixes"? Should we thus have 360 namespaces all containing one class called "Morph"? :)
Ehm, noting of course that the design is bad in the first place - it should not be different subclasses of Sockets at all. But my point is still made - we should not use the word Socket for tons of different things.
It's an example, but something more real will come up soon enough.
Sure, there are "overloaded" words that we tend to use quite a lot. But fine, use them, the only thing it leads to is the system will ask which one you mean and you will have to read them fully qualified - if it is not a local reference. The price is quite cheap IMHO.
In other words, with only one level the Namespaces end up having the same "prepending prefixes" problem as classes have now.
I don't think so, you can probably come up with an example - but I think it would be quite rare.
You just showed me one. :)
I don't think so.
Actually, I think the biggest reason is that we (we being we who are using prefixes) don't want to "pollute" the global space. And yes, we do want to avoid clashes - but not because it would be terrible but because we currently don't have mechanisms to deal with them.
And we will still need them with a one bucket namespace system for the same reason. "Smalltalk" just becomes something a bit more narrow, but otherwise it's the same situation.
We will still need what? I am lost.
But my point still stands - we don't *need* a space for every package.
I didn't say we would for *every package*.
I am not sure I caught the "confusing" part.
Because different systems call the concept different things. C++ has something very simple and they call it a "namespace". I think everyone else calls the concept either "package" or "module". This may lead one to conclude that the terms mean how the given languages implement them (e.g. since C++ namespaces are simple and Lisp's packages are complex then namespace must mean something simple and package something complex).
Are you saying we should call it something else or? I am calling them Namespaces OR Prefixes improved. I am not calling them modules, packages etc.
I am not saying "They will hardly be used!" - you just said that, not me.
I didn't say you said it, but that it "seems like", in other words, this is how it sounds to me.
Not sure what you mean.
For the base classes I *do* believe that. Because we are already maintaining that namespace together and it is working just fine. I didn't mean for the whole world of Squeak.
As you said yourself, we already effectively have namespaces: prefixes. We are not living together in harmony, we're making namespaces the only way we can. This is what I mean, how can you think we will have one or 2 when we don't today? We have lots.
I never said "one or 2". I wrote *base classes*. We don't use prefixes in there. We are maintaining it cooperatively and it works just fine.
This is an interesting statement that tries to argue that in 5 years we will have much more libraries and code and that this will linearly increase the number of conflicts. At first sight this seems logical BUT it totally ignores the fact that you only get a naming conflict INSIDE AN IMAGE.
And since the number of libraries and code in a given image is not likely to increase all that much (some yes, but not much) the reasoning fails.
You misunderstand me. I'm not saying in 5 years we will have vastly more libraries. Just the ones we do have converted to namespaces.
Lost again. :) How can merely moving to namespaces (adding prefixes basically) create conflicts?
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
Andrew Tween -
Bert Freudenberg -
Blake -
Brent Pinkney -
Chris Muller -
Cédrick Béler -
Damien Pollet -
David Mitchell -
Enno Schwass -
goran＠krampe.se -
Göran Krampe
-
Igor Stasenko -
Jason Johnson -
Jason Shoemaker -
Keith Hodges -
Michael Davies -
Michael van der Gulik -
nicolas cellier -
Paolo Bonzini -
Ramon Leon -
Ron Teitelbaum -
stephane ducasse -
Tansel -
Tony Garnock-Jones