Brainstorm

[goran.krampe at bluefish.se]

Hi!

Alexandre Bergel <bergel at iam.unibe.ch> wrote:
> Just some quick comments:
> 
> > 1. A module is a separately deployable unit of objects, typically
> > including classes. I think this definition is a good one.
> 
> What a module is for? When one would choose to use it? Is it for deploying application? Is it to share source code? Is it to save/share EToys stuff and other scripting mechanism? 

I just followed the proposed "definition" by Alan Lovejoy which a few
other people also thought sounded good - incuding Colin Putney IIRC. The
emphasis is on *deployable* and *objects*, meaning not only source and
not typically partitions made for SCM (like Monticello etc) but for
actual deployment. I still think it is a good start and the answer to
your questions would be:

- It is for deployment and distribution of applications and libraries.
Since it is not constratined to only source code it could apply for
eToys too I guess or any other "part of the image that you would like to
distribute".

- It is not primarily for SCM management, we have Monticello and various
other tools that are more capable with merging mechanisms etc etc. A
Module is in this aspect more "low level". My current belief is that a
Module would simply be a "chunk of the image" with defined bindings in
it (=named objects), and most often it would contain initialized class
objects but not necessarily only so.
 
> What is the model behind the technical details that you gave? Me, as an end-user, I do not really have to care that ImageSegment is used or not, or that a module can be easily unloaded by putting a ref to nil. The system should do that for me.


You seem to miss that I posted a "brainstorm" - I am expecting you to
storm with me, not just shooting it down :). And yes, the end user
wouldn't care - but I am deliberately talking about implementation in
order to make this much more tangible and concrete.

In the end I want a clear cut easy to understand Module concept -
because if it is not easy to understand then it will fail, mark my
words.

> For me, it is really not clear why and for what we need modules.

I can see several reasons, but claiming it is "clear" to me, I do not.
:) This Team is exploring the area, so let us explore.

> To share source code, I think that Monticello is not bad, regardless the lack of first class package that implies some naming convention.

I agree.
  
> > and Metaclass (superclass of Baba class, right?)
> 
> Not really.
> (Baba class) superclass == (Baba superclass) class
> 
> Baba class class == Metaclass

Yes, I think that was a typo, I meant "class of Baba class, right?".

> Cheers,
> Alexandre

cheers, Göran