Colin,
I agree that code management is one of the problems
that is trying to be addressed by the modules effort(s).
>So again, I don't think I understand your concern. Are you saying that
>you prefer the SM/DVS route to 3.3 modules?
Well, I guess that is more or less what I'm saying.
> How do you define "modular" and "monolithic?"
I save an image, and when I restart a Squeak VM, it comes back with
*everything* exactly the way I left it. I call that "monolithic".
Your point that keeping multiple Squeak images around is a
"Good Thing" is significant (IMO). Squeak is a "virtual
machine" and running multiple virtual machines on one "real"
machine with different images in each is a perfectly
reasonable thing to do.
I start up a Sqeak VM and it goes hunting all over my disk (and
possibly the network) looking for bits and pieces that it thinks
it's supposed to have to build an image before I can do anything
useful. That would be one kind of "modular", and I wouldn't like
it.
-Dean
-----Original Message-----
From: Colin Putney [mailto:cputney@whistler.com]
Sent: Thursday, October 31, 2002 4:09 AM
To: squeak-dev(a)lists.squeakfoundation.org
Subject: Re: An uncomfortable question
On Wednesday, October 30, 2002, at 05:33 PM, Swan, Dean wrote:
> Colin,
>
> Consider the case where there are dependencies between the modules and
> more than one version of each module. The current effort of
> implementing modules is attempting to deal with these issues, and it
> is a non-trivial problem. It is also possible that because of certain
> interdependencies between different versions of different modules that
> some modules may become mutually incompatible. This situation is
> witnessed with MS Windows .DLL libraries quite often.
>
> One common effect is that some applications have to be installed on a
> Windows machine in a particular order in order for them to all
> function properly on the same machine. There can arise instances
> where because of different sets of .DLL versions required, a set of
> applications may not all function correctly on one machine.
Well sure, incompatibilities between different parts of the system is
always a danger. Certain parts of the system expect particular
behaviour from other parts of the system. If you make changes you run
the risk of violating those expectations. This is true whether those
parts are modules, classes, functions or DLLs.
The nice thing about Squeak is that you can have multiple images lying
around. So if you need different versions of a module in different
situations, you do that without having to say, swap out your hard drive
when switching between applications.
Now, this is not to say that dependency tracking, versioning and so on
is a non-issue. It is a problem that we're going to have to address.
But the ability to build images for specific purposes is a mitigating
factor. So when we do have incompatibilities between modules - and it
will happen - instead of "hell" we're faced with a mere problem.
> And regarding SqueakMap and DVS, realize that these are based on the
> monolithic image model. They are more or less fancy user interfaces
> to manage filing in the various change sets (I know I'm
> oversimplifying a bit, but the point is still valid).
Hmm. It sounds like we have different definitions of "monolithic." When
I speak of modularizing the image I mean grouping the code into
clusters of classes and methods that a) provide a distinct and coherent
piece of functionality, and b) interact with other clusters through
well defined interfaces. Once that's accomplished (and yes, it's a
non-trivial task) many of the clusters can be removed from the base
image and maintained separately.
I place that scenario opposite the "monolithic" system used by Squeak
3.2. Everything is really intertwined and you can't easily remove any
functionality from the image. Adding functionality is easier, but still
quite a hassle because of the some what artificial distinction between
"blessed" code that's maintained by SqC and other stuff, which is
floating around in ChangeSets.
So again, I don't think I understand your concern. Are you saying that
you prefer the SM/DVS route to 3.3 modules? How do you define "modular"
and "monolithic?"
As to SqueakMap and DVS, sure. They really are just tools to make it
easier to move code in and out of images. But that's the point! The
whole problem here is that it's difficult to manage code.
> Of course, monolithic systems have the issue of shared namespaces
> which can make it difficult to make different packages play nice
> together in the same image, so like I said, the problem is > non-trivial.
>
> While it would certainly be possible to produce an MPEG player image,
> with only the items necessary to play MPEGs, and a MIDI image with
> only the items needed for MIDI processing, and so on, factoring out
> the common components can be difficult. This is especially true when
> some "applications" use different versions of a particular component
> and rely on some characteristic behavior. A hardware example of this
> is the 4046 phase locked loop IC. It is a fairly standard part, BUT
> the Motorola Version and the Philips versions are incompatible in that
> the external timing components require different values to get the
> same frequency out of the two parts. The same kind of thing can
> happen in software.
No, it's not trivial, but it can be solved, and it's not even all that
difficult.
For one thing, the package model used by DVS makes the problem easier
by virtue of its inflexibility. A given package can contain classes and
methods. When a package is loaded, it can create classes and it can add
methods to existing classes. It cannot modify methods belonging to
another package, and it can't delete methods. So it avoids all kinds of
problems that can arise when modules can modify each other.
A second factor that makes the problem tractable is that Squeak images
offer developers much more control over the execution environment than,
say, a desktop operating system. For development, you can build an
image that has exactly the configuration you need - all the right
packages, of the right versions, loaded in the correct order. For
deployment, you just distribute that image. There's no need to have
users load your package into whatever randomly configured system they
happen to be running. That's the situation that creates DLL hell and it
just doesn't apply to Squeak.
And finally, if you do run into a compatibility problem, just fix it!
The source code is there, there's a community of people willing to
help, and with SqueakMap and DVS, you've got the tools to easily
distribute your fix to the rest of the community and to easily benefit
from their efforts. As Daniel mentioned, we've got a social advantage
over the commercial world.
Cheers,
Colin
