richard at simula.no wrote:
> goran.hultgren at bluefish.se asks:
> > > i believe modules/modularity is the most important problem to be solved
> > > in the squeak world, and i have been reading most postings regarding
> > > this topic, but still do not buy into the proposed solutions.  i'm
> > 
> > what do you not buy into? just curious.
> 
> I don't buy in because no one is selling.  You and your collaborators

:-)

> clearly have much more expertise in this area than I have, and you are
> proceeding without design documentation that people like me can

It has some historical reasons, but sure - the documentation for the
design etc can always use more work.
You have to understand though that the developers moving this forward
are doing so "one piece at a time" - it's exploratory development
because we just can't see all implications before we have some code.
That is at least my impression.

> understand.  I'm not complaining; just stating as fact that I don't yet
> understand how the current effort will satisfy what I see as basic
> requirements for Squeak modules.  
> 
> I know some of this has already been discussed in the group, so no need
> to reply.  But if it helps, here are some basic stories for how I think
> a module system should be used:
> 
> Sharing Objects: Peter begins with the Squeak-vN.M image, adds objects
> to create functionality F that passes test suite F.test.  Peter
> publishes this functionality as a module named F that is dependent only
> on Squeak-vN.M.  Pat can use another Squeak-vN.M platform to locate
> module F by name in a repository.  Squeak-vN.M can load module F from
> the repository and immediatly run and pass the test suite F.test.

Currently we have not discussed versioning "whole Squeak" I think.
But otherwise I see no problem with the above - in fact this story
probably works already.
 
> Dependencies: Pricilla can create module G passing tests G.test, that
> depends on F.  Pat can start again with a fresh Squeak-vN.M image and
> load module G.  Module F and any other dependencies may be loaded
> automatically.  Pat may run G.test immediately after the load of module
> G completes and the test suite will pass.

This also works, at least given you know the repository (but that will
be remedied by my SqueakMap).
Currently the ModuleInstaller resolves, downloads, installs all
dependencies needed.
But do note that there are probably tricky situations that we need to
work out.

> Evolution: Pam may change the interface semantics of F and publish the
> changes as F-v2.0 (She cannot publish with a version number that is
> already taken).  Paul may create a new module H passing tests H.test,
> that depends on F-v2.0.  Pat can; with the same image that runs G.test
> with modules F and G; load module H and successfully run H.test.  The
> required module F-v2.0 will be loaded automatically and execute without
> conflict with the earlier version.

This is where it gets tricky. Versioning of modules and conflict
resolution. This is one area being worked on.
Stephen Pair has produced some classes for a good version numbering
scheme etc.
I don't think we have yet agreed on how/if different versions of module
X can coexist.

A lot of discussion about versions, dependencies, conflicts has been
going on but I am not sure we have reached any "final solutions" yet.
There are various questions and part solutions like Stephen's "selector
spaces" etc. that makes the issue even more thorny.
 
> Shrinking: Peter begins with a Squeak-vN.M image and wants to shrink the
> image by unloading all modules not needed to execute a given test suite.
>  The system is able to mark all modules required by the test suite and
> unload all others automatically.

Actually, this will probably be done "backwards". Peter will begin with
a kernel and then simply fully load the test suite/module. That will
bring in everything needed but nothing more.

> Growing: Pat is able to begin with a tiny Squeak image that is able to
> do little more than evaluate small talk expressions from an input stream
> and load modules from the network.  From this image, she can input an
> expression to send a #start message to an object defined in an arbitrary
> module.  The system can locate and load the module by name, instantiate
> the object and send the message.  Code in the module may, in turn, refer
> to other objects in other modules that are loaded in similar fashion.

Well, ok. Currently Modules do not contain "objects" but more or less
simply code.
This is also under heated discussion of course. Personally I would say
that we focus on "code" to begin with and look at objects later when we
have learned more.

> The questions this set of requirements raises for the current module
> design (as I read it at http://minnow.cc.gatech.edu/squeak/2247) include
> the following:
> 
> 1. We are not allowed to have a module with arbitrary objects?  Can we
> have a module that includes just an Array of Form instances?

Objects in modules are under discussion. The current implementation does
not "think in terms of" object but in terms of modules of code. I
haven't formed a good opinion myself other than the fact that we could
try to solve "code" before trying to tackle "objects".

> 2. Is it too much burden for the programmer to indicate dependencies? 
> The example at http://minnow.cc.gatech.edu/squeak/2449 implies that the
> programmer must search for dependencies and document them.  Why can't
> the programmer just 'import' the modules they choose and let exceptions
> be raised if they type a global name that cannot be found?

Dependencies are indicated manually by the programmer but you can also
use tools to discover them and optionally add them etc.
In short - this is a user interface problem, you can do it either way.

> 3. Will we be able to lazily load modules so that dependencies are
> resolved only if that code path is actually executed?  Are we able to

Well, we could probably add such a "lazy detection" facility.

> eagerly load modules so that execution will not be delayed by the need
> to load more modules?

That will probably be the default as a Module should normally depend on
all other modules it needs and they will all normally be installed in
one big swooop.

> 4. How small is the code needed to locate and load modules?  Is this
> core small enough to allow Squeak to run in a light switch?

:-) I think it's kindof small, but I have no measures.
My addition, SqueakMap, which will be needed to fully resolve module
paths etc is not large and I have selected a "simple" design to keep it
small and so that it only depends on "vanilla" Squeak classes.

> Richard

regards, Göran