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
|