slimming the image

Roel Wuyts rwuyts at vub.ac.be
Wed Aug 2 05:10:43 UTC 2000


>> A counter-example is Emacs.  Emacs has *tons* of code available for it,
>> and yet it all tends to work nicely together with any subset of the
>> modules loaded.  And Emacs doesn't even have namespaces!  It's all done
>> by hand.
>>
>> I don't know why it works out, but it certainly does, somehow or another.
>> It's at least *possible*.
>
>   The reason why Emacs handles the complexity (module
> dependency) better might be partly because the presense of
> "built-in" mechanism, such as require/featurep/autoload: the
> submodules declare which module depends on which with those
> mechanism.
>
>   It would be nice if the user can declare the module
> dependency in class definition or in class-category, and
> those declarations are included fileouts.
>
>   However, Emacs also suffers from the same problem, IMO.
> For example, the independent minor-modes tend to conflict in
> keymaps and something like that.
>
>   -- Yoshiki  (at Pacific Time)
>

I strongly believe that some form of modules/typing/aspects/... is closely
related to the issue of slimming the image (and being able to do so in a
repeatable, (semi-) automatic way).

One way to start this could therefore simply be to define some 'core' pieces
of code, and start documenting these. Since several people started doing
this (but, I guess stopped, since this is hard work to do by yourself), it
should be possible to make a Swiki-site where we can start drawing
boundaries.

The next step would be to document these classes, for example simply by
putting in the class comment the name of their module first, and then the
rest of the module. This is just a ferst step, and perfectly doable in a
current system. Once it is done, a simple enumerator could already fetch all
the classes in the modules (because we categorized them by hand).

The next step would be something to make this better structured, extensible
and processable. Maybe some stuff is already out there. Or maybe Mat's
rework of the parsetree and the compiler will help. We could, for example,
add comment in a specific format that could be retrieved as module
descrition, and simply enumerate this. This would also allow the finer
grained categorization (e.g. also methods, instance variables, in the limit
individual statements!), since this is just a node in the parsetree.

At the ends of these steps, you would have some system that, once it is
tagged manually, can be used to support slimming the image. Then comes the
more fancy stuff that interests me (and some of my colleagues in the lab) a
lot: helping with the categorization. For example, when the complete
Collection hierarchy, except some classes, should be in a module, it would
be nice to just say so in a tool, that would do the appropriate stuff
(adding comments, updating parsetrees, ...). Or typing the instance
variables to help finding relations between classes (I use a lightweight
typing scheme to support this in my logic language, and it gives remarkable
results). Or... or ... or ...

And of course there are intersection with this and the actual storing of
source code too. But I guess some people know much more of this then I do...


--
Roel Wuyts                    Programming Technology Lab
rwuyts at vub.ac.be              Vrije Universiteit Brussel
http://prog.vub.ac.be/~rwuyts
Webmaster of European Smalltalk User Group: www.esug.org





More information about the Squeak-dev mailing list