On Feb 13, 2005, at 10:56 AM, Lex Spoon 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.

Argh, I am agreeing with Lex again. ;)  Requiring PI subclasses seemed 
odd to me.

> ...
> (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.)

Which explains why there isn't a good Refactoring Browser for C++. ;)

> ..
> The only compelling case I see for a subclass at this point, is to deal
> with installation code.

I agree.  That is a pretty compelling reason, though.

> 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?

That sounds better to me.  And the class would have a limited number of 
methods in its API... #initialize, #unload, #reload (or similar, I 
didn't think hard about these names).  The class could be named 
MorphicPackage, etc.  It'd still be the place to go for package 
information.

Would this be an easy change?  I don't want to get "stuck" on this 
point.

If not, I suppose we could proceed with using PI subclasses, with the 
understanding that only the 3-4 API methods above should ever be 
implemented in the subclasses; overriding other PI methods would be 
strongly discouraged.

Whatever we do, I agree with Daniel that the tools should automatically 
handle whatever the "best practice" is, when creating a new package. 
(e.g. creating the PI subclass or package class for you)

> 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.

The very few I've looked at do not seem to override much except 
#initialize and that sort of thing.

- Doug