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.