A Proposal for Project Layers

David Cramer dacramer at videon.wave.ca
Mon Oct 11 17:27:55 UTC 1999


I am always concerned by "registration" proposals. Couldn't we employ a
"magic folder" approach instead? In the case of registration, some kind of
magic (base) file needs to be edited to contain the desired reference to an
added package AND the package has to be located wherever the reference says
it is. On the other hand, with magic folders, a package merely has to be
located in the magic folder. The base code doesn't contain specific
references to the packages, it just contains a protocol for dealing with
the permanently specified magic folder(s). The package protocol determines
the necessary form for the package to announce its requirements, whatever
they are.

Obviously, this can be seen as the difference between the Mac Extensions
folder on the one hand, and the Windows Registry on the other. (I have a
feeling Unix systems may also have registry-like features, but they're not
monolithically mandated?) Considering the constant frustrations with being
unable to remove programs from the Windows Registry and the frequency of
corruption and general hair-pulling, it would seem to be incredibly
preferable to build a Squeak package protocol based on a
permanently-registered folder system with simple rules for declaring code
requirements, instead of a file registry system with its attendant dangers.

(I sure hope this isn't a stupid idea!)

Regards,

David

On Sun, 10 Oct 1999 Dan Ingalls responded:

>Moreover, I take your choice of a "regular expression package" to
>exemplify some code that might want to be used almost anywhere but, of
>course, if not in use it should not clutter up the rest of Squeak (neither
>browser-wise nor space-wise).  Therefore this layer would be "registered"
>in (presumably) the "Base" system -- ie in the topmost system dictionary.
>What does this mean?  Almost nothing more than that it would look very
>much like a PoolDictionary today, with an entry such as #RegExpPkg in
>Smalltalk, and with the various regular expression classes defined in it.
>When you need to parse a regular expression, you would write, eg,
>
>	parse := (RegExpPkg at: #REParser) parse: someParsableString.
>
>This is admittedly clunky, but I'm purposefully exhibiting the most
>ungainly form in the thought that it could only get better.  [Obviously
>dot notation is another approach, but please keep responses regarding the
>path construct private to me -- we already discussed this a lot a few
>months ago].
>
>The point is that I think little more is needed beyond registration and a
>path construct to address the basic need you describe.
>
>There is one detail for which I don't have an answer in the context of
>packages.  In the case of *entering* a project it is reasonable to support
>layer-specific changes to system classes above, using the isolated
>projects mechanism.  However I do not see how to do this for a dynamic
>call such as the above.  My inclination is simply to disallow changes to
>sytem classes in registered packages.
>
>	- Dan


David Cramer, Process Innovation Evangelist          87-1313 Border Street
PBSC Computer Training Centres (an IBM company)      Winnipeg MB R3H 0X4
Corporate Office Research & Development              Canada





More information about the Squeak-dev mailing list