[Modules] So many modules, so little time... what to unload?

stephane ducasse (home) ducasse at iam.unibe.ch
Wed May 22 19:52:14 UTC 2002


Hi Andreas

I completely agree with you. I think that when you analyse the references
you want to get rid of

- 1 the ones that are local to the class in the same level (submodules for 
example if you take alice categories as submodules of Alice (I do not like 
that but the module system produces that automatically right now)).
-2 the ones that belongs to the prerequisites of the module (Alice here).

Daniel have you looked at the pages were I tried to explain the queries I 
did  to analyse some subsystems. I do not know where Henrik moved them from
http://scgwiki.iam.unibe.ch:8080/SmalltalkWiki/156
but did not put a link to Swiki ;)

Stef

On Wednesday, May 22, 2002, at 09:10  PM, Andreas Raab wrote:

> Daniel,
>
> I might point out here that the structuring level is partly inadequate.
> If I look over your list, then I immediately notice that...
>
>> Squeak Media Balloon3D Alice Misc
>> Squeak Media Balloon3D Alice Scripts
>> Squeak Media Balloon3D Alice Undo
>> Squeak Media Balloon3D Alice Interface
>
> ... the class references you're seeing are almost certainly coming from
> Alice internal references. It seems unwise to me to have a very fine
> granularity level at this early stage of refactoring. As an example, I
> am pretty certain that _none_ of this Alice stuff is referenced from
> anywhere but within Alice itself. Thus it should unload with no further
> action required. And it appears to me that by using the fine grained
> structure at this point we'll be left with figuring out how to bend over
> backwards in the module system just because the structure doesn't fit
> yet. Making the above unloadable as separate modules might be a nice
> exercise if you want to understand what kind of issues you might run
> into in a module system (since I'm pretty certain there are all kinds of
> circular references) but it's an absolutely pointless exercise if you
> want to make actual progress. So why not go for it and unload just _all_
> of it in a single module?!
>
> My feeling is really that we need to cut a few rough lines through the
> system after which we can establish finer areas of control. And I also
> think you could more easily establish a "working group on cutting out
> everything 3D related" rather than finding somebody who knows how to
> make "Squeak Media Balloon3D Alice Cast AliceConstants" unloadable ;-)
>
> Note that having large parts go first will also help to establish
> cleaner lines later on. Since we really don't understand yet what the
> boundaries ought to be it just feels right to say 'we have an "Alice"
> module' and later - when we understand how this is separated -
> restructure it in a more appropriate way and just make the new internal
> structure a prerequisite of "Alice" so that anyone relying on "Alice"
> will still be able to use it even if later refactorings are applied.
> Right now this is worrysome for me because with this fine-grained
> approach we are relying on structures which we already know to be
> inadequate (at least for the 3D stuff this is certain).
>
> Cheers,
>   - Andreas
>
>




More information about the Squeak-dev mailing list