Spoon progress 15 April 2006: inert method deletion details etc.

Craig Latta craig at netjam.org
Mon Apr 17 03:19:43 UTC 2006


Hi all--

	Wow, it took me over a day to realize I'd written the wrong year in the 
original subject line. :)

	Thanks to all for the encouragement!

	Chris Muller writes:

 > Craig, it sounds like you will have a 3.8-compatible system that can
 > "breathe" code in and out; methods can be GC'd or dynamically
 > re-installed on demand.  I think this "upgrade path" could really help
 > Spoon become the basis for future Squeaks.

	I hope so!

 > Can one master image serve multiple target images?

	Yes. One of the original scenarios I envisioned was broadcasting a demo 
to an audience at a conference. Yours sounds like a good one, too.

 > Does it preserve the package semantics (i.e., class categories) when
 > it brings methods so I can save new streamlined Monticello packages?

	Yes. It's all done by modules synchronizing with each other. The target 
modules can be functionally equivalent to the sources, or completely 
new, as one wishes.

 > Does Naiad use class categories in its packaging scheme or something
 > different?

	They're optional, rather like source code. Currently, each version of a 
class object (independently of the methods) is associated with a module, 
and each version of a compiled method is associated with a module. 
Everything else is optional annotation. This is a good time to talk 
about design wishes.

 > Is there a way to know if any methods were installed *recently*?

	Yes, you can get each method's module to tell you when the method was 
installed, from which host, etc.

 > I could imagine someone deploying a gutted target image to
 > "production" and leave the master image connected for the first couple
 > of months. There might be some "nervousness" to disconnect the master
 > image unless assured no methods had faulted in the last month under
 > heavy usage...

	I must admit (not surprisingly :) that I'm a fan of using test cases to 
establish coverage, and improving the test cases over time. I also think 
this is markedly different than static typing advocacy; in fact, I think 
they're near polar opposites. The static typing people seem to want to 
use it in large part as a hedge against testing. I think testing is 
critical and unavoidable, and we may as well use the information we get 
from it to the fullest. But sure, there are still pitfalls to deal with.

	On the subject of type characterization, Colin writes:

 > I'd be interested in a method marker that uses type inference to mark
 > all the methods in a given package, as well as all the methods it
 > depends on, even indirectly. Then you could easily build images for
 > specific purposes without worrying about test coverage, or providing
 > the complete range of expected inputs during imprinting.

	That would be interesting, but I'm more interested in the reverse: 
using method marking to inform a type inferencer. :)


	thanks again,

-C

-- 
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]




More information about the Squeak-dev mailing list