Quick comparison of two Namespaces proposals
siguctua at gmail.com
Mon Sep 17 12:15:20 UTC 2007
On 17/09/2007, Göran Krampe <goran at krampe.se> wrote:
> Hi folks!
> I just read through Michael van der Gulik's page:
> 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:
> 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.
> - 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
> - 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
Igor Stasenko AKA sig.
More information about the Squeak-dev