MajorShrink and MorphicShrink
Kevin Fisher
kgf at golden.net
Wed Feb 7 03:05:32 UTC 2001
>
>
> > Perhaps we should have more than one variation on majorShrink? We could still
> > keep the 'classic' shrink that shows how small we can get it...and perhaps
> > others, like shrinking for PDA usage (what would we need for a PDA?)
>
> On the other hand, the methods in 'shrinking' category
> have been (always) forgotten to be fixed when a new feature
> was added or the organization was changed. having more
> variation means that making it harder to keep those methods
> up to date.
This is true. I should correct myself...when I do a shrink I usually end up
hand-removing what's left over that I don't want as well. There were lots of
new features that weren't in the majorShrink. :)
>
> In my experience, and I think you will agree, what I
> wanted to remain in the stripped-down image was quite
> different from the image for a purpose to another. I always
> ended up with a big "Workspace program" which contains all
> necessary expressions to strip down the image.
Yes, this is a good point.
>
> So, I'd vote for not having the variation in the base
> image.
>
> Just my US$ 0.02.
>
> -- Yoshiki
Perhaps just having a good 'majorShrink' method as an example is enough. I
constructed my own shrink method based on that anyways. :)
I was wondering (and I have no idea how 'do able' this is)...instead of
'shrinking' an image discarding bits and pieces, is it possible to say "This
class is the main class...discard everything this class (and it's subclasses)"
do not depend on?
...Something like 'Smalltalk shrinkWrap: Celeste' that would strip everything
out that is not used by Celeste or it's component objects, leaving behind
basically a stand-alone Celeste application.
Comments? Is this crazy? Do-able?
More information about the Squeak-dev
mailing list
|