Peeping At The KeyHole

Dear Squeakers,

    Ralph Johnson kindly wrote:

> Most Smalltalk classes build on a lot of other Smalltalk classes.
   
    My English is not very good. Is there any difference between
    "on" and "from".

> So, they are hard to understand until you know the classes that
> they use.

    I thought so too.

> In fact, you can't print out Object and completely understand it,
> because it has methods like "inspect" that call a lot of other
> classes.
> It is possible to build the image up from a small base, but it is not
> done one class at a time. Each layer is partly new classes and partly
> adding methods to existing classes.
> This is a good thing, not a bad thing, but it makes it harder to learn
> Smalltalk.

    Is this a rule, that I have to add methods to existing classes?
    Would you please explain why it is a good thing.

    What if the authors of the existing classes don't want
    anything added to their classes?

    What would Squeak be like if no one(including the owners)
    were allowed to add anything to existing classes?

> When an expert teaches Smalltalk, it is like getting a guided tour of
> a city. We show just the part of Smalltalk that a beginner is able to
> understand, and avoid the parts that are confusing until they have the
> background.
> You don't get that by looking at the image. For example, I tell people
> to ignore the GUI, the compiler, and all the tools at first.

    I would like to ignore more than that.
 
> Just focus on Collection classes and numbers.

    I like to ignore these as well.

> We spend several weeks with just the core classes
> before we move on to other things.
> The GUI is way more cool, but I think students learn better
> if you ignore it at first.

    I like to concentrate on just the cluster of the _smallest_
    core classes that they can exist by themselves with no
    dependency on any other classes.

    How can I identify this cluster, the "KeyHole" classes?

    I think these are the coolest of them all ;-)

> Unfortunately, one of the disadvantages of Smalltalk over Java
> is that it is harder to learn on your own.
> It is not hard to learn with a guide, but newcomers don't know
> what to look at and what to ignore.
> It would help to have a beginners browser that hid most of the
> classes that beginners want to ignore anyway.

    I know there exists a small 3plus4.image (15KB)
    and wondering how was that image produced?

    Is it an art or a science?
    (Please spare me the ambience ;-)

    I would like to get an image with just "KeyHole" classes.
    Is it possible?

    Your help is very much appreciated.

    Cheers,

    SmallSqueak

    P.S:
    It would be interesting to see what can be ignored on the
    VM side to build a VM just to run this KeyHole.image.

    All external plugins (including WindowPlugin) can be
    ignored?

    Platform dependent codes may boil down to just
    printf to display the activities of the objects?
    (I am thinking of calling this VM, "Peep" ;-)

    InterpreterPlugin and ObjectMemoryPlugin are surely
    needed, but what about PrimitivesPlugin?

    Of course, it may not be as interesting as playing with the
    robots in a shining polished, cleaned kitchen sink ;-)

Dear SmallSqueak,
 
 >> Most Smalltalk classes build on a lot of other Smalltalk classes.
   
>    My English is not very good. Is there any difference between
>    "on" and "from".
 
 In this context, no real difference.

>    Is this a rule, that I have to add methods to existing classes?
    Would you please explain why it is a good thing.

 You don't have to, but you can if it suits your purpose.  Its a good thing because it allows proper delegation responsibility.
 
>    What if the authors of the existing classes don't want
    anything added to their classes?
 
 Adding something to a class only adds it for you and no one else.  Everyone is free to enjoy whatever experience they want, so you can add/change/delete code anywhere you want.
 
 Just like you can paint your Toyota a different color if you want, its your choice, and has no effect on Toyota or anyone else, so nobody cares.
 
 Just like for free software, anyone is free to modify it and repost it at a different location.  Others will either use it or not.

>    What would Squeak be like if no one(including the owners)
    were allowed to add anything to existing classes?

 Not "allowed"?  How would I be prevented?  
 Even if it were possible, I think it would stagnate.
 
>    I like to concentrate on just the cluster of the _smallest_
    core classes that they can exist by themselves with no
    dependency on any other classes.

 You might be interested looking at Craigs spoon project, which I think can start with a minimal "keyhole".
 
    http://www.netjam.org/projects/spoon/
 
 Welcome, enjoy!
 

Ralph Johnson wrote:

> On 5/1/06, SmallSqueak <[hidden email]> wrote:
> About adding methods to existing classes ....

> >   Is this a rule, that I have to add methods to existing classes?
> >   Would you please explain why it is a good thing.
 
> You don't have to, but you can.  You can't do it in C++ or Java. 
> It is a good thing because sometimes when you want to extend a system,
> you want old objects to interact well with new objects, and it is easier
> if you can add methods to old objects.  And I really mean "old objects"
> and not just "old classes", though of course that is included.
 

        In C++ and its derivatives if I have the source for the whole
system,
        can I just add methods to any class I want to then rebuild the whole

        system?

        Would the effect be the same as what you are saying for Smalltalk?

        I can't really see that this is good software engineering practice.

        My C# friends used to talk about data hiding, encapsulation, public,

        private, protected, internal, virtual, ... what a mouthful!

        Is there a name for this technique of adding methods to existing
classes?
        Is there some reference on this technique? I want to do some
googling
        and show off to them ;-)

        Just for curiosity reason, are there any other OOP languages that
allow
        this practice?

> Suppose you want to add a new kind of tool to the system, one that helps
you
> debug objects.  You want to be able to send a message "debug" to every
object. 
> You can add a default "debug" method to class Object and override that
method
> in classes that need a different implementation. 

        If you don't have access to the source code of Object, can you build

        this debugger?

        When it's time to upgrade/update the Smalltalk system, do you have
        to go to each of these classes that you modified to repeat the whole
        procedure.

        Would it be cumbersome if the new version of Smalltalk has the
methods
        with the same name as the ones you added?

        BTW, would this technique help or hinder the efforts to make Squeak
        modular? The whole Squeak community have been struggling for several
        years to modularize Squeak but it looks like no one really knows
how.


> >   What if the authors of the existing classes don't want
> >   anything added to their classes?
 
> When you publish the source code to something, it is a gift to the world. 

> The world can do what it wants with it.  If you think the world is better
off
> without adding methods to a particular class, by all means write a comment

> to that effect. 
> But you might be wrong, and the world will show you by adding methods
anyway.

        That's true.
       
        The spirit of my question was that what if for one or another
reason,
        you cannot change existing classes, what would you do to implement
        your debugger.


> > > Just focus on Collection classes and numbers.

> >   I like to ignore these as well.
 
> I think this is a mistake.  The collection classes are very important. 
> They are also great examples of well-designed Smalltalk classes.
 

        Please don't get me wrong. I certainly will have a good look
        at the collection classes after fully understood the KeyHole
        classes.

        To me this is the only way I can ever make any progress in
        learning Squeak. I call it SmallLearn ;-)

        The hard part now is how can I identify the KeyHole classes
        and satisfy myself that they are truly smallest cluster of
        independent classes, using various browsers available for Squeak.


        Cheers,

        SmallSqueak

 

On May 2, 2006, at 12:02 AM, SmallSqueak wrote:

> In C++ and its derivatives if I have the source for the whole
> system,
> can I just add methods to any class I want to then rebuild the whole
>
> system?

Sure

> Would the effect be the same as what you are saying for Smalltalk?

Yes, the problem is that you seldom have all of the source code for  
the entire system.

> I can't really see that this is good software engineering practice.

I can't see where its bad.

> My C# friends used to talk about data hiding, encapsulation, public,
> private, protected, internal, virtual, ... what a mouthful!

This is the C++ cargo cult.  So many basic ideas behind C++ are wrong  
but have been adopted by the masses anyhow.  Witness the vast number  
of people who believe static typing is holding back the forces of  
darkness.

> Just for curiosity reason, are there any other OOP languages that
> allow this practice?

Apart from Smalltalk, have a look at "method categories" in ObjectiveC.
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ 
Articles/chapter_4_section_7.html
http://en.wikipedia.org/wiki/Objective-C

There is also an experimental feature known as Traits - a bundle of  
methods that can be attached to any class provided the class  
implements an underlying enabling protocol.  Traits are written in  
terms of the classes methods and cannot access ivars directly (where  
categories are bound to a class at definition time and can access  
ivars).  Traits can only call methods.  The Traits paper is http://
www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf

> If you don't have access to the source code of Object, can you build
> this debugger?

Smalltalk can do reverse compilation when necessary.  Usually, all  
source code is available.

> When it's time to upgrade/update the Smalltalk system, do you have
> to go to each of these classes that you modified to repeat the whole
> procedure.

No, there are various code management strategies including changesets  
and Monticello packages.

> Would it be cumbersome if the new version of Smalltalk has the
> methods
> with the same name as the ones you added?

That would be inconvenient in any language.

> BTW, would this technique help or hinder the efforts to make Squeak
> modular? The whole Squeak community have been struggling for several
> years to modularize Squeak but it looks like no one really knows
> how.

It can do either, depending on how it is done.

> To me this is the only way I can ever make any progress in
> learning Squeak. I call it SmallLearn ;-)

There is a new mailing list specifically for helping beginners get up  
to speed you might want to join.
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Hi SmallSqueak,

on Tue, 02 May 2006 09:02:03 +0200, you wrote:
...
> ... The whole Squeak community have been struggling for several
> years to modularize Squeak but it looks like no one really knows
> how.

Have a look at the current effort for the 3.9 release, perhaps after  
looking at

- http://www.iam.unibe.ch/~scg/Research/Traits/

to find out if no one really knows how to modularize Squeak.

/Klaus

Klaus D. Witzel wrote:
> Have a look at the current effort for the 3.9 release, perhaps after
> looking at
>
> - http://www.iam.unibe.ch/~scg/Research/Traits/
>
> to find out if no one really knows how to modularize Squeak.

Interesting. Can you elaborate on how you think traits deal with/help
modularization? I would actually (from my current point of view which is
based on the available examples) claim the opposite - traits being a
tool for "more reuse" seem to make relationships between classes and
their (compositions of) traits even more intricate than before. At least
that's the feeling I get when I look at their current use for defining
the metaclass hierarchy (if anyone has a better real-world example I'd
be interested in studying it; but please no toy examples ;-)

The relations between the fifteen or so traits that ultimately make up a
class seem to be fairly elaborate and (in my eyes) much more fragile
than I would have expected. To give an example, have a look at
TBasicCategorisingDescription (which I chose at random, the same applies
pretty much to all of these traits) - even by roughly glancing over the
trait I find several methods that are implemented nowhere in sight but
that have very specific requirements (#organization, #organization:,
#includesSelector:, #isClassSide, #classSide) which strikes me as very
unmodular indeed. It seems in particular problematic that there is no
information which of these selectors are actual (computational)
requirements, which ones are (assumed to be) state and which ones are
simply bugs (by elimination). There is zero information about the
interface of these requirements (arguments taken, return values, error
conditions), whether the methods are assumed to come from a common
(required) trait or whether it's just a loose collection of random
methods (like, for example, a utility trait for implementing unrelated
math functions). All of which I think are critical if you want to build
a modular system (and btw, much of that information *is* readily
available as soon as a trait is used in a functioning class but that's
exactly the point here - traits themselves definitely loose some
modularity when they try to stand on their own -modular- feet).

So to me it really does feel as if, yes, reuse is being maximized, but
modularity is actually being sacrificed in that process. Also, remember
that duplication of code is not necessarily a bad thing if one tries to
minimize dependencies which is typically a good idea for modularity.
Contrary to which one of the primary goals of traits is to maximize
reuse and minimize duplication which makes the goals at least somewhat
incompatible. And although one could argue that the expected gains of
traits offset the loss of decoupling I get the distinct feeling this is
not true for the examples we currently have - if I would want to reuse
any of these traits I really wouldn't know how (other than in precisely
the same form they're already being used in). That, I think, was the
most surprising result when looking at actual code but it may partly be
related to tools issues (although I doubt that because no tool will tell
you what a non-existent method's expected return value is if you load a
trait and have no existing composition at hand to look at).

Now it may be that this is not a good example but it's the only
real-world traits use that I've seen so far (toy examples discounted).
Anyway, if you think that example is badly chosen or if you have another
example that shows how traits help modularity (or even if you just have
gut feelings ;-) I'd be interested in hearing more about it.

Cheers,
   - Andreas

Hi Andreas,

Your point of view is very interesting.

Can we imagine a system where user specifies a minimal set of features, that
is a list of classes and protocols (i mean traits), and then where dependency
on other classes and traits is automatically infered ?

As not statically typed, i'am not sure that this is ever possible, but some
tools might assist the user in selecting...

I did not have time to test Spoon until now, but that may well be a pragmatic
answer taking the reverse problem...

Maybe a mixture of two approches make sense ?

Nicolas

Hi Andreas,

on Tue, 02 May 2006 11:28:49 +0200, you <[hidden email]> wrote:

> Klaus D. Witzel wrote:
>> Have a look at the current effort for the 3.9 release, perhaps after  
>> looking at
>>  - http://www.iam.unibe.ch/~scg/Research/Traits/
>>  to find out if no one really knows how to modularize Squeak.
>
> Interesting. Can you elaborate on how you think traits deal with/help  
> modularization?

Sure. And apologies in advance if this becomes too theoretical. O.K. base  
things first, from wikipedia:

"A module can be defined variously, but generally must be a component of a  
larger system, and operate within that system independently from the  
operations of the other components."

The emphasis, IMO, is on "...operate within that system independently from  
the operations of the other components".

Every Traits is such a module, also the composition of two or more Traits  
qualifies (IMO without any doubt).

I use a simple judgement to see if something qualifies for being a module,  
a raw translation from the work of
- http://scholar.google.com/scholar?q=Anne+Berry+separator

a) there are at least two modules in any non-monolitic system which  
deserves to be called "modular"
b) there are pairs of modules which are independent from the operations of  
each other
c) if a) and b) then there is/are one or more things (the users of  
modules) which separate pairs of modules

> I would actually (from my current point of view which is based on the  
> available examples) claim the opposite - traits being a tool for "more  
> reuse" seem to make relationships between classes and their  
> (compositions of) traits even more intricate than before.

This is quite possible and I agree that the example of traitified Traits  
(TBasicCategorisingDescription et al) can be seen this way.

But I think that at this stage of the Traits story we do not have a  
convincing view on the relationships between Traits and users of Traits  
(and between Traits themselves). We just use GOFBrowser as before but what  
is needed (IMO) is a shift in the paradigm of "...a query path into the  
class descriptions, the software of the system...". Not that I have a  
concrete idea on how such a thing would look like, but without any doubt  
I'd recognize it if someone showed it to me (no, it won't look like  
http://www.eclipse.org/ ;)

This is, again in my eyes, a direct consequence of the modularization  
effort of the author of these requirements: it tells me that the author  
didn't want to know anything about how a Behavior decides  
#includesSelector: and how a Behavior manages #isClassSide and #classSide,  
and that {#organization. #organization:} are just getters/setters.

> It seems in particular problematic that there is no information which of  
> these selectors are actual (computational) requirements, which ones are  
> (assumed to be) state and which ones are simply bugs (by elimination).

Out of curiosity, why do you want to know which ones are state?

> There is zero information about the interface of these requirements  
> (arguments taken, return values, error conditions), whether the methods  
> are assumed to come from a common (required) trait or whether it's just  
> a loose collection of random methods (like, for example, a utility trait  
> for implementing unrelated math functions).

Don't get me wrong but isn't this the case for *most* methods in Squeak?  
If you can agree then we can put this issue aside (until "somebody" fixed  
the documentation problem, I mean ;)

> All of which I think are critical if you want to build a modular system  
> (and btw, much of that information *is* readily available as soon as a  
> trait is used in a functioning class but that's exactly the point here -  
> traits themselves definitely loose some modularity when they try to  
> stand on their own -modular- feet).

I agree, this (your comment) comes close to my a)-c) view from above, in  
the sense that modules are "nothing" in the absence of their user(s).

> So to me it really does feel as if, yes, reuse is being maximized, but  
> modularity is actually being sacrificed in that process.

Well, my impression is quite the opposite: only because the author *did*  
this (IMO high) level of modularization, he/she was able to lay the ground  
for maximizing reuse of this particular Traits. Of course if there is only  
*one* user, then... But I also think the author has given Traits traits as  
a high level example on how to do "it".

> Also, remember that duplication of code is not necessarily a bad thing  
> if one tries to minimize dependencies which is typically a good idea for  
> modularity.

This is the point at which I view users a separators: have a look at the  
average non-traitified classes and how they are used: the more "glue" code  
a user needs, the less the value of modularization. Take for example  
Http-readable content, to be paired with CrLf conventions: no way unless  
one accepts to read the entire contents, before being able to apply CrLf  
conventions by using an *existing* module (this is just an example, no one  
take this personal, please).

Agreed, this amounts (again) to a shift in the GOFBrowser paradigm.

> Now it may be that this is not a good example but it's the only  
> real-world traits use that I've seen so far (toy examples discounted).

I'd say the example you used is a good one. It is fairly complex and is  
part of something which everybody in squeak-dev understands: behavior.

> Anyway, if you think that example is badly chosen or if you have another  
> example that shows how traits help modularity (or even if you just have  
> gut feelings ;-) I'd be interested in hearing more about it.

I hope it was possible to demonstrate my view on modularity and Traits.

/Klaus

Hi Klaus,

    Many thanks for reminding me about Traits.

    I would be very happy to be wrong here and
    will publicly apologize when the kernel image
    is released together with a Morphic package.

    Cheers,

    SmallSqueak

Hi SmallSqueak,

on Tue, 02 May 2006 16:15:59 +0200, you <[hidden email]> wrote:

> Hi Klaus,
> ...
>     Many thanks for reminding me about Traits.

You are welcome :)

>     I would be very happy to be wrong here and
>     will publicly apologize when the kernel image
>     is released together with a Morphic package.

With kernel image, did you mean

-  
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/096029.html

If that was not what you meant then please give URL.

/Klaus

>     Cheers,
>
>     SmallSqueak
>
>
>

Hi Klaus,

>
> >     I would be very happy to be wrong here and
> >     will publicly apologize when the kernel image
> >     is released together with a Morphic package.
>
> With kernel image, did you mean
>
> -
>
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/096029.html
>

    No, sorry.

> If that was not what you meant then please give URL.
>

    Sorry, again.

    I think that URL won't be available until The Board
    announces the release.

    IIRC, many moons ago, it was discussed here that
    there should be an official Kernel Image on which
    other packages like MVC, Morphic, Tools... can
    be loaded to build various other images to suit
    many different needs.

    The Kernel Image is the result of the modularization
    of the last Kitchen Sink Image.

    After that the kitchen sink will be placed in the dusty
    museum and RIP.

    Cheers,

    SmallSqueak.

This is the main difference between a Smalltalk system and a conventional
system.  In all other environments for the most part you need to start your
application with no objects, and create each and every one explicitly.  Even
if you load them from a data file your application needs to create them each
time it runs.  This creates multiple representations of the same
information.  It exists both on the disk and in RAM in different forms.
Keeping those two forms in sync becomes a major undertaking and a large
source of errors.  There is no GC for objects on disk for example.  Only the
GemStone database provides live objects that are persistent and active
without explicit run-time recreation.  Of course it is Smalltalk based as
well.

Michael

> Well not quite the same. In Smalltalk all existing objects in the
environment would get the new behavior so > one can add new methods to
"live" objects. This distinction can't be overstated.  Language to language
> comparisons can be useful but comparing a grove of orange trees to an
individual apple often isn't very
> helpful and can sometimes be very misleading. If you take time to wander
in the grove of the Smalltalk
> environment for a bit, you'll start to see things differently. You may in
fact find  situations for which 
> Smalltalk isn't the best tool to employ, but it probably won't be because
of a language feature. In my
> experiences, it usually is because of a schedule/level of expertise factor
or  something to do with the
> politics of the decision-makers.

> Cheers,
> Laurence

Klaus D. Witzel wrote:
[Andreas critiques Traits decomposition of behavior as an example of
modularization by Traits]
> I'd say the example you used is a good one. It is fairly complex and
> is part of something which everybody in squeak-dev understands: behavior.
Actually, I think Behavior and friends are hugely complex, very little
understood, were not brought to a local minimum of complexity when
Traitified (not that I blame anyone), and therefore make for a terrible
example on how to do modularization using Traits. AFAIK, the main reason
to Traitify behavior, was that the implementation of Traits itself
otherwise requires duplication. A good reason in itself, but it doesn't
solve the need for a good example.


>> Anyway, if you think that example is badly chosen or if you have
>> another example that shows how traits help modularity (or even if you
>> just have gut feelings ;-) I'd be interested in hearing more about it.
I've read the paper about factoring collections using modularity, and I
thought it added quite a few interfaces that are meaningful and thin,
and at least some of the Traits have names that it makes sense should exist.

Haven't read the code though, and its not a live example, AFAIK. So
Andreas' question stand lively...

Daniel

> In C++ and its derivatives if I have the source for the whole
> system,
> can I just add methods to any class I want to then rebuild the whole
>
> system?
>
> Would the effect be the same as what you are saying for Smalltalk?

Yes, except you had to do a lot more work (i.e., rebuild the entire
system).

> I can't really see that this is good software engineering practice.

Proper delegation of responsibility is absolutely good practice.  What
is poor software engineering practice is what a closed system like Java
forces developers into; creating "Utility" classes, usually just a
bunch of static methods (functions!) with a bunch of parameters just to
accomodate the need.

> My C# friends used to talk about data hiding, encapsulation, public,
>
> private, protected, internal, virtual, ... what a mouthful!

After twelve years with Smalltalk and six with Java, I have realized
this is all unnecessarily-complex computer jargon, none of it is really
concerned with addressing the problem domain.

What do your friends do when the statically declared access modifier is
not what they want; simple, they go and change it!  Its a rubber stamp
that clutters the program and does nothing to protect a running
program.

> Is there a name for this technique of adding methods to existing
> classes?
> Is there some reference on this technique? I want to do some
> googling
> and show off to them ;-)
>
> Just for curiosity reason, are there any other OOP languages that
> allow
> this practice?

All OO languages I know of allow it.  Note I do not consider Java an OO
language.

> If you don't have access to the source code of Object, can you build
>
> this debugger?

Smalltalk is an open system, you always get the source code.  I would
not use a closed system.

> When it's time to upgrade/update the Smalltalk system, do you have
> to go to each of these classes that you modified to repeat the whole
> procedure.

Like any system, upgrading your software to work with new versions of
the system involves merging the code into the new system.  Thanks to
Monticello, merging is one of the eaiest things to do with Squeak.

> Would it be cumbersome if the new version of Smalltalk has the
> methods
> with the same name as the ones you added?

Yes, it would require some extra work to rename the methods.  The
Refactoring functions make that rather trivial.

The key though, is to not "hog the namespace" with
inappropriately-generalized names in the first place.  In my
experience, method name collisions have never been a real problem.

> BTW, would this technique help or hinder the efforts to make Squeak
> modular? The whole Squeak community have been struggling for several
> years to modularize Squeak but it looks like no one really knows
> how.

Packages were a major step in the direction of modularizing Squeak.

I hope the Spoon project will lurch Squeak beyond all other systems in
modularisation.

It should be noted, so far, the only real benefit to extreme
modularisation (that I see) is reducing size of the image (which is
already much smaller than standard Java footprint anyway).  Unless
wanting to run on a PDA or specialized application, a small image isn't
such a big deal.

> That's true.
>
> The spirit of my question was that what if for one or another
> reason,
> you cannot change existing classes, what would you do to implement
> your debugger.

Don't know, I would never use such a rigid, closed system.

Regards,
  Chris

Hi Chris--

 > ...the only real benefit to extreme modularisation (that I see) is
 > reducing size of the image (which is already much smaller than
 > standard Java footprint anyway).  Unless wanting to run on a PDA or
 > specialized application, a small image isn't such a big deal.

        I think the most important benefit is making the system easier to
understand. With that, one can more effectively and pleasantly compose
and decompose systems.


-C

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

> I think the most important benefit is making the system easier to
> understand. With that, one can more effectively and pleasantly compose and
> decompose systems.

> -C

Even if the entire image retained all the same classes/methods making it
modular and well layered will improve understanding of the system for those
wanting to understand the underlying system.

Modularization will help to a degree the novice user as well, but not as
much.  Knowing that certain methods were added by a module informs the
purpose of the method a bit more, but does not really help in the slow
introduction of complexity from a novice's point of view.

Modularization will also impose a bit more discipline on the development
process and help organize the work.  That can only be a good thing.  The
effort in modularizing will also have found issues that got cleaned up that
might not have been found otherwise.  It will also make it easier to produce
more special purpose images for headless use and so on.

Hi Daniel, you wrote:

> ...
> Andreas wrote:
>>> Anyway, if you think that example is badly chosen or if you have  
>>> another example that shows how traits help modularity (or even if you  
>>> just have gut feelings ;-) I'd be interested in hearing more about it.
> I've read the paper about factoring collections using modularity, and I  
> thought it added quite a few interfaces that are meaningful and thin,  
> and at least some of the Traits have names that it makes sense should  
> exist.

Old reliable collection hierarchy seems to be the one and only example for  
so many software (re)engineering approaches ;)

-  
http://scholar.google.com/scholar?q=formal+concept+%22smalltalk+collection+hierarchy%22

/Klaus

Good point, seeing only the code that is the result of execution, very cool.
 
 BTW, how did you ever solve your issue about methods implemented in superclasses..
 
 i.e., in the master image I have MyDomainClass>>#name, but Object>>#name has already been faulted down, so I'm not getting the correct implementation because DNU was not invoked..
 
 

----- Original Message ----
From: Craig Latta <[hidden email]>
To: [hidden email]
Sent: Tuesday, May 2, 2006 1:18:25 PM
Subject: Re: Peeping At The KeyHole


Hi Chris--

 > ...the only real benefit to extreme modularisation (that I see) is
 > reducing size of the image (which is already much smaller than
 > standard Java footprint anyway).  Unless wanting to run on a PDA or
 > specialized application, a small image isn't such a big deal.

    I think the most important benefit is making the system easier to
understand. With that, one can more effectively and pleasantly compose
and decompose systems.


-C

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