modularity

Andreas Raab andreas.raab at gmx.de
Wed May 24 09:07:44 UTC 2006


Hi Craig -

>  > I'm curious but how exactly does this help for modularity? Since I
>  > haven't used Spoon so far I don't really know what to look for here...
> 
>     (If you haven't read them already, you might find the previous Spoon 
> progress reports[1] interesting.)

Yes, thanks for pointing it out.

>  > ...but it'd be great if you were willing to share a few success
>  > stories, or even if there aren't any yet just your reasoning about why
>  > you think these abilities are an important step.
> 
>     The main success story I have with Spoon is in reducing the size of 
> a complex, unmodularized application (OpenAugment), without having to 
> analyze how it was put together or what exactly its prerequisites were. 
> I did this by using imprinting between the large development object 
> memory where the application originated and a small deployment memory. 
> My goal was simply to make the application small, but the resulting 
> artifact provided a useful basis for actually understanding the 
> architecture of the application and its dependencies.

That's *very* interesting to me. Modularity is one of those areas where 
theory goes only so far and having a practical example is really 
important to study real-life implications of the system. For example, 
personally I was (well, still am ;-) somewhat hesitant whether 
imprinting will be good enough to capture all the corner cases; the 
cases that happen "one in a thousand" (like a file not being there) and 
may require a set of methods that's not available at runtime (e.g., 
after imprinting). I'm curious - how do you deal with that issue in 
practice?

>     By imprinting methods directly, immediately as they were invoked, I 
> was assured of installing each method and its literals (particularly 
> classes) in the proper order, and that I wouldn't waste time or space 
> with things which were already present. You don't get this when using 
> source code and/or static files for transferring behavior.

I think you do, just on a different granularity (modules) and not quite 
as elegantly ;-) But that's a little besides the point here.

>     As for the three aspects I mentioned:
> 
> -    Having unconstrained class names allows each author to name classes 
> however they please, and makes it easier for code from different sources 
> to coexist. (We would probably want the development tools to visually 
> distinguish a class name appearing in source code when the name is 
> shared by multiple classes, and provide a means for getting more 
> information about the particular class associated with a particular 
> occurrence of the name.)

So what does Spoon do to make this work? Does every module have its own 
(local) namespace to map names freely to UIDs/classes? (that's what I am 
leaning towards for Croquet ;-)

> -    Being able to transfer behavior directly between systems increases 
> delivery accuracy. A module isn't much good if, when applied to a target 
> system, the behavior it is meant to convey is not properly installed. 
> When the transfer medium is static files, the author effectively has to 
> guess at what the state of the receiving system will be at installation 
> time.

True, but isn't this a different problem? Without the files at the 
beginning aren't we risking that we basically arrive at some "fixed 
point" for each system that we can't leave without breaking things 
horribly? [Not that this really matters at this point but I'm curious 
about the philosophical implications here]

>     The remote-messaging infrastructure surrounding the use of live 
> module objects also enables other useful abilities, like browsing and 
> even running the behavior associated with a module in the providing 
> system (by opening remote browsers and other tools directly on the 
> providing system), before ever deciding to install it locally.

Yeah, that's a little bit like Croquet when you open a browser on a 
replicated portion of code ;-) Except that in Croquet that code is 
already there but it would be fairly simple to write a browser which 
shows code in a "remote" island (one of the nice things about a remote 
messaging framework is how widely it's applicable to various 
applications - a Croquet replicated message can trivially be implemented 
as a message to a single client on a remote machine).

> -    Being able to associate multiple methods with the same method 
> signature avoids another major source of collisions (and places similar 
> demands on the tools that unconstrained class names do).

Yes, I think that's essentially the same as the class name/uid 
distinction. How do you deal with this problem? (my inclination 
currently is to do the same, e.g., have a selector name space per island 
and map the messages to UIDs or somesuch).

>     thanks,

This is very interesting, thanks a lot!

Cheers,
   - Andreas



More information about the Squeak-dev mailing list