Partitioning the image (was Re: Shrinking sucks!)
Bernhard Pieber
bernhard at pieber.com
Sun Feb 13 15:07:30 UTC 2005
Avi Bryant <avi.bryant at gmail.com> wrote:
> Just to inject something into the discussion: originally, PackageInfo
> required a subclass for each package. To get the default behavior, it
> didn't have to do anything but sit in the correct class category, but
> you could override things like #packageName and so on if you wanted.
> I ended up removing this requirement because it seemed a little
> heavyweight to create a whole PackageInfo subclass for every small
> package.
>
> 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 am very much in favor of this approach! See my reasons, reusing a mail
I sent on November, the 17th:
I suggest we use PI subclasses instead of PI instances. I find them much
better for the following reasons:
- They are more straightforward to put into the update stream. ;-)
- They are more explicit than PI instances and thus easier to
understand.
- For some packages we need to have subclasses anyway because there is a
need for overwritten messages. Using PI subclasses for all packages
reduces the number of necessary concepts by half (from two to one ;-)
and is thus easier to understand. Think STTMPW.
- With PI subclasses there is a natural place to put things for a
package, should the need arise. Think package documentation. ;-)
- The PI subclasses would be a natural place to put code for package
initialization, reinitialization, loading, unloading.
- Monticello could be more easily used for versioning and merging
package meta-information.
- They would be very similar to ENVY applications and subapplications
and thus very easy to understand for former ENVY users.
- Porting code from and to VW/Envy and VA would be easier.
Therefore, I vote for making subclasses mandatory.
Thanks for your attention!
Bernhard :-)
More information about the Squeak-dev
mailing list
|