Partitioning the image (was Re: Shrinking sucks!)

Lex Spoon lex at cc.gatech.edu
Sun Feb 13 15:56:42 UTC 2005


Avi Bryant <avi.bryant at gmail.com> wrote:
> However, one advantage of doing it that way is that it provides an
> obvious place to hang things like package comments, and potentially
> lots of other interesting metadata (like how to access the
> corresponding SM package).  It also provides a nice declarative form
> of the package declaration - ie, it makes it extremely obvious how you
> add a PI to the update stream.  So maybe we should think about making
> those subclasses, if not mandatory, at least a strongly encouraged
> best practice.

I don't think we should use PI subclasses.

I wouldn't call PI subclasses a declarative approach, but in fact the
opposite.  It defines packages in terms of arbitrary Squeak code.  To
process such package info's, you have to load and execute code that the
package writer defined.  This makes PI's themselves very flexible, but
the cost is that the *tools* become more limited.

A stark example is tools which process packages that haven't been loaded
yet.  Do they have to load and execute custom per-package code just to
do things like list what is in the package or to give a description of
the package?  Further, what if the custom code only works in certain
Squeak versions?  It's a drag to not even be able to process a package. 
What if you are trying to port it to a different Squeak version?

Even leaving that aside, there are other tools you cannot write if
PackageInfo is arbitrarily extendable.  Consider a rename-package tool. 
How can it work, if it doesn't know for sure the algorithm the #classes,
etc., methods are using?  Heck, consider a simple move-class-to-package
tool.  We surely want this, but how can you implement it with the
subclasses proposal?

Subclasses are great for experimenting, but if we want to move forward
and write a bunch of package-aware tools, we need to commit to a single
model that the tools can rely on.  Experimenters can continue to make
subclasses if they want, but the tool-writers shouldn't need to deal
with arbitrary changes.  And thus, Joe Developer shouldn't be making a
subclass, either, if they want the standard tools to work with their package.

(This is a general tradeoff in language design.  General programming
languages don't even have a solvable halting problem!  If you limit the
language, then there are fewer things you can express in the language,
but there are more tools you can write to help you deal with what you've
expressed.)

It looks like people have a pretty good feel what should go into a
PackageInfo at this point.  The standard #classes, etc., methods are
very good I think.  Also, all PI's should have an optional link to a SM
entry (and, if we want to be serious about making stable releases, a
Universes entry).  All packages should have installation and
deinstallation code.  (and re-configure code....) 

The only compelling case I see for a subclass at this point, is to deal
with installation code.  I really hate code in strings!  Maybe instead
of a PI subclass, this code code be in some other class, and the PI
could have a symbol which names which class the code is in?




So what else have people been putting in these subclasses?  Is there any
real barrier to pushing it up into a single general class?  If we can do
that, then there are a lot more tools we can write to make it easier to
use packages.



-Lex



More information about the Squeak-dev mailing list