sounds coooooool colin.

Stef

On 24 févr. 05, at 7:25, Colin Putney wrote:

>
> On Feb 22, 2005, at 7:53 PM, Dan Ingalls wrote:
>
>> Meanwhile, I'd like to proceed simply to ask for people interested in 
>> putting modules into Squeak.
>
> Hi Dan,
>
> Chalk me up as interested in modularizing Squeak, as designer, 
> implementor and user.
>
> One of the motivations for OmniBrowser was the observation that any 
> modularization scheme would need tool support, and the current browser 
> is an obstacle to that because it's difficult to modify. Indeed, the 
> early versions of OB included package browsers based on PackageInfo 
> packages, but I took those out on feedback from the community.
>
> I agree with Florin that versioning is a key part of organizing 
> Smalltalk code. One of my biggest frustrations with Monticello is that 
> it's not been of any use to the Guides and Harvesters. That is, it's 
> great for applications built on Squeak, but not so good for Squeak its 
> self. I'm now working on a version of Monticello with a redesigned 
> versioning engine, which I hope will be more useful in managing the 
> kernel and core libraries of Squeak. More on this in another post.
>
> I also implemented an experimental packaging system a few months ago, 
> complete with an OB-based set of  browsers. It's not quite finished, 
> and I'm not sure it's the way to go, but it's interesting nonetheless.
>
> I quite like Alan Lovejoy's characterization of packages as units of 
> separately deployable code, and I hope that doesn't get overlooked in 
> the all the discussion of versioning, categories, namespaces, 
> dependencies and so on. All those things are necessary to some degree, 
> since they are ways of dealing with the additional complexity that a 
> packaged image brings with it, but they're not end goals in 
> themselves. Separately-deployable packages is what we're after.
>
> Some more specific things I'd like to see.
>
> - Decoupling the organization of the image (packages, environments or 
> whatever) from the compiler's strategy for resolving names. This will 
> make things like compiling in a sandbox, building small images, 
> atomically loading packages and so on much easier.
>
> - Good tool support for packages. Browsers, debuggers, changesorters, 
> testrunners, etc should all be package-aware.
>
> - Good tool support by packages. With a little care, we can make core 
> execution machinery *much* easier to manipulate, and thus make it 
> easier to write good tools. ClassBuilder is a good example: it is very 
> difficult to deal with any other way than through the class definition 
> doIts that appear in the browser.
>
> - A fast-loading and compact format for distributing code.
>
> Thanks for taking this on, Dan. I think it's really important.
>
> Colin
>
>