Modularity again

Colin Putney cputney at wiresong.ca
Wed Aug 9 02:50:18 UTC 2006


      On the squeak-dev list, Dean writes:

> Regarding modularity, wasn't there an Idea that future work would be
> based on Craig's Spoon work?  That at least offers a repeatable
> process:
>
> 1) Start with a "full" image version X.Y-Z, execute some method(s)
> designed to exercize the desired funcionality to imprint a new
> "minimal" image
>
> 2) Save the minimal image and give it a name/version. It seems that
> S-unit tests of some sort would provide the basis for the method to
> imprint the desired functionality.
>
> Is there any reason why this isn't a good path to follow?

      Andreas responds:

> As the *only* path? Or as part of an overall strategy? If the first,
> I'd say that I'll answer that question once I've seen the first system
> that has been built that way ;-) ["once bitten, twice shy"] As part of
> an overall strategy it's perfectly fine - there are various
> interesting ideas in Spoon which can be helpful in many different
> contexts.

      I  respond:

> I'll echo this opinion. Spoon does nothing to make the system more
> modular.

    Craig rebuts:

> I assume you mean that Spoon provides no tools for untangling the
> current mess of behavior. That's not true.

I mean that Spoon doesn't untangle the current mess of behavior. Yes,  
it provides tools that might help with that. Yes, it provides tools  
for dealing with modules once they have been separated from the mess.  
These are excellent things.

So far, though, nobody has used those tools to do any untangling.  
Note also that Dean's proposed path, which I've quoted above,   
doesn't involve any rewriting or refactoring, only unloading. So I  
think Andreas is right. A modularization strategy that involves Spoon  
is a fine idea, as long as it also includes the kind of ugly grunt  
work that Andreas, Pavel, Edgar and others have been doing to  
disentangle the mess.

Colin




More information about the Squeak-dev mailing list