Hi all!

Niko Schwarz <niko.schwarz at gmx.net> wrote:
> Am Montag, 3. Februar 2003 13:28 schrieb goran.hultgren at bluefish.se:
> 
> > Well, the image is in fact simply wonderful - a world of objects that
> > interact with each other with full dynamics. But of course the freedom
> > and dynamics of an image makes modules etc much more complicated. But as
> > a Smalltalker I would never give up the image just to get "nice
> > modules".
> 
> Hey Göran, how about self which joins code and image into the same thing. To 
> be honest I like the idea of self that the separation of classes and objects 
> is unnecessary, and I love the slot concept too, which draws no difference 
> between function calls and accesses to instance variables.

I agree - both these aspects of Self are intriguing. I haven't worked in
self so I can't say anything from personal experience.

> I think modules should contain objects too. When you draw no difference 
> between image and code, you need no gui-builder, cos you can simplystick 
> together some widgets to a gui and then save it somewhere in the snapshot, 
> and when code needs the gui, it simply loads the gui, without constructing it 
> widget by widget. 
> And when modules contain objects anyway -- why would we bother to separate 
> code and object space?

Well, personally I think it comes down to a matter of how we want to
think about our software artefacts. Even if Self proved that "Hey,
classes are unnecessary" I don't think we would construct better and
clearer software if we simply started mixing behaviour and data "as we
please" and forgot about classes. I bet that Self programs *have*
classes, they are just not called that.

The idea of building UIs "by hand" and then simply keeping the instances
around has been tried several times and AFAIK it has been shown to have
its own problems. One issue is that object structures can be quite big
and complex and when you develop code that builds them it can be very
easy to simply change a line and then affect the complete structure. If
there was no code to change then you would need to try to change the
structure "in place" instead of simply rebuilding it from scratch.

Another issue is that the objects you use in your UI may have changed
(new version of the UI toolkit for example) and you need to evolve your
code to fit with the new toolkit - not very easy to do either.

But anyway - the issue of focusing on "objects" instead of "source code"
in the modularization effort has been discussed a lot on this list
previously. IMHO I think that "simplifying" the question by saying that
- hey, if we instead base the modules model on objects then "the rest
will follow" simply is an oversimplification.

Anthony has been pushing this idea earlier (I think) and I don't claim
to know the truth or have more knowledge than he has (I certainly don't)
but I still think it is an "oversimplification".

To try one more silly analogy (I know it is limping but perhaps my point
can be understood anyway):

We all know "everything" in the image are objects, much like molecules
are in real life. Now, let's pretend that the image is the human body
and that the different modules are the organs - the heart, brain, lungs,
limbs etc.

If I told a surgeon that "Hey, if you just figure out how to keep track
of the dependencies between the molecules in the body - then you will
as, a sideeffect, have solved the problem of knowing the dependencies
between the organs!".

I think the surgeoun would laugh at me. He would say that, "It's a bit
more complex than that. You can't just figure out how the organs
interact by looking how the molecules connect to each other. For
example, the heart pumps blood out into the other organs. So all other
organs are dependent on the heart. But many of the organs aren't even
touching the heart are they?"

Whatever - I will stop my silly analogy here. ;-) Two small facts I
stand by:

1. Smalltalk code is our way of capturing the dynamics of the image in a
declarative way. We need declarative descriptions of our systems to be
able to think about them - it's just the way we work as humans. At least
until we can plug the computer directly into our brains. Simply dragging
and drooling will not cut it (instance based programming á la Parts or
whatever).

2. The dependencies in Smalltalk code are hard to capture and describe.
It is not impossible but do not underestimate the problem. People who
have tried like Joseph Pelrine and Henrik Gedenryd (two different
approaches) can surely tell us more about the complexities involved. I
also guess that Allen Wirfs-brock can tell us more about what is
involved too. No pressure intended. ;-)

regards, Göran