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
|