"Andrew C. Greenberg" wrote:
> 
> >I appreciate your point of effectively "put up or shut up" in terms of
> >implementing suggestions. Generally that is the right thing to say if
> >said tactfully in an open source context. Except in THIS case. This
> >isn't just a whine about a bug to be fixed or a widget to be added.
> 
> I disagree.  Put up or shut up.
> 
> Sure, major changes are necessary.  We've all seen major changes
> produced, some inside and some outside of SqC.  A fork has never been
> necessary, and major progress has been made in a very short time.

We obviously disagree somewhat on this, which is fine (see my 11 Mar
2001 14:00:38 -0000 comment for more details of why I think SqueakC
should make modularity a priority even for their own sake).

But, let's say for the sake of arguemnt you are right. Do you (or anyone
else) have any ideas for how to make a modular Squeak in such a way that
it would be easy for SqueakC to integrate it into ongoing changes?

Here are the requirements (defined by how Python does things):
1) Building an image from scratch (equivalent to Python creating an
image in memory from *.py files loaded at run time by the core EXE)
2) Loading modules (defining one or more classes) as needed from files
(equivalent to the Python import statement)
3) Supporting namespaces for a module for sanity and to ensure needed
classes are loaded (like Python)
4) Tagging modules with version numbers and checking they match
acceptable versions when they are loaded (Python doesn't have this
except as done adhoc by the code itself, so this would be an optional
later part -- perhaps similar to ENVY)

I can't see how to do (2) or (3) without going in and modifying hundred
or more likely thousands of methods in how the reference other classes
and modules, in addition to creating the modules. I can't do (4) without
having 2 and 3. Perhaps the first item (1) (building an image from
scratch using a text definition) could be split off, but even it would
require hundreds of methods to be revised to eliminate class
dependencies if it were to be useful (i.e. so you could just have the
compiler without a GUI -- which might involve the exception handling
system and related upgrades). Any change of hundreds or thousands of
methods would mean a fairly painful integration into a moving
development base. Also, all of these require substantial new code to be
written to be really effective (e.g. remote debugging of a headless
image) although presumably that could be done more independently.

Anyway, if people have suggestions on refining either these requirements
or an approach that makes modularity more doable independent of SqueakC,
or perhaps quantifying estiamtes of how much work it would take beyond
these rough guesses (e.g. number of methods that refer to classes by
name), I'd like to see it.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com