Hi Lex,

I can't say I am particularly happy that you don't agree with me on this
topic. I know it is difficult to argue with you. ;-) Still, I'll give it
a try!
"Lex Spoon" <lex at cc.gatech.edu> wrote:
> 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.
I am a big fan of a declarative approach of modelling code. When I
propose to only use PI subclasses, I am not arguing you should put any
number of methods you like there. On the contrary, there should be a
very minimal set of messages which should be put there, so that they
keep their declarative feel. So my motivation is not the flexibility
this brings but the simplicity.

> 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?
That is an interesting question. I tend to think that it should be
possible to have only the PI subclass loaded, without loading all the
rest.

> 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?
Frankly, I don't understand at all what you mean by this. Why shouldn't
I be able to rename a PI subclass? Oh, can it be that there is a big
misunderstanding? I don't want to use a PI subclass because I want to
use different algorithms for finding classes, etc.! I want to use
classes because I know I will eventually *need* package specific code,
namely
a) preload, postload, preunload, postunload code
b) image save and load code
c) instance migration code
Part of that stuff is what makes ChangeSets really useful and that's the
*only* thing which is missing currently from the declarative approach
Monticello brought us. And if we want to replace the ChangeSet-based
update stream with a Monticello-based process we will need to adress
this anyway.

My reasoning goes like this:
1. If I need code for some things, I need a class because I want to
reuse all the tools, browsers, completion, Shout, you name it. I want
senders and implementors to work! I don't know how this work should work
if you put code in strings. It doesn't find code in preambles and
postscripts, does it?

2. If I sometimes - and I think that will be more often the case than
you think - need a class anyway, let's always use a class. And I am
talking about abstract classes, so they have no instances! And if I
already have a class I can as well put the other information a package
needs there. Why bother and put it somewhere else?

3. To use exactly on abstract PI subclass for a package is the simplest
thing that might possibly work. ;-)

> 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?
Great, we seem to agree here about code in strings!

> 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.
I agree with you that *everything* should be in the superclass
PackageInfo except all the package-specific code.

Thanks for your attention!

- Bernhard