a namsepaces discussoin! (Was: Re: Partitioning the image (was
squeak-dev.sourcery at forum-mail.net
Mon Feb 14 03:58:21 UTC 2005
Thus spake Yanni Chiu:
Something that's missing in the discussion is what level
of abstraction we're dealing with. If you're packaging
a large domain of objects, then package==namespace makes
sense. But if you're packaging a few enhancement methods,
then package==namespace, seems wrong.
Another issue is "private" versus "public" declarations. Not all global
variables declared in a module should be "exported" by the module as
"public" names. One way to implement this is to use "private" auxilliary
namespaces that are not organically bound to any particular module. This
idea so similar to pool dictionaries that it makes a lot of sense to merge
the two concepts.
Also required is separating the issue of the namespace in which a class is
declared from the issue of the set of namespaces whose bindings it imports
(although it shouldn't be necessary for a class to explicitly import the
namespace in which it is declared.)
Finally, for some of the reasons Yanni mentioned (which I didn't quote,) it
is important to separate the issue of class, module and namespace identities
from their names. A professional module/versioning system should treat
names as changeable attributive values associated with specific versions of
a programming construct, not as invariant primary keys identifying the
construct diachronically for any and all versions.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev