Dependencies, Squeak Code Control [proposal, long]

Hannes Hirzel hannes.hirzel.squeaklist at bluewin.ch
Tue Nov 18 22:39:14 UTC 2003


Peter van Rooijen wrote:

> Goran, Stephane, et.al.,
> 
> 1) Let's assume, to define terminology for the sake of argument, that when
> talking about dependencies and configurations, we are thinking of all the
> code (the classes and methods that do the actual work) that is involved as
> being contained in a Module.
> 
>     - A Module is either a Package or a Bundle.
>     - A Bundle contains (zero or more) Modules (composite pattern!).
>     - A Package contains code = classes and methods (i.e., no other
> Modules).

Well the first point seems to be easy to understand;
Module as abstract superclass of Bundle and Package (composite pattern)



> 2) Let's note that there is a versioning aspect to this domain. When we talk
> about a Module (a Bundle or a Package), we actually have two notions to deal
> with:
> 
>     - The Module identity (the thing that groups all its versions).
>     - The Module version.

This is easy to understand as well. An important distinction which often 
gets blurred in everday language.


> 3) Module Requirements and Configurations are declared things (someone
> defines them, as opposed to them being dynamically derived), which both
> describe relationships between Modules (Configurations additionally describe
> relationships involving Maps and Modules - see below).

Here in fact I perceive gaps in the line of arguments. Could you 
elaborate and  tell us what Module requirements are? Definitions and why 
you introduce them ....


Thank you for this interesting contribution.

Hannes







More information about the Squeak-dev mailing list