Hi guys...

Nice thread!

I have a different felling...

Do we want modules/packages/theNameYouLike?

We must be absoluty sure the benefits pay the complexity we're adding.

My answer: I don't want the extra complexity that modules add. IMHO, Changesets + Dependencies + Uninstallation of Changesets is more than enough.

<related>
Do we want the extra complexity that Metaclass hierarchy had added?
</related>

Cheers,

Diego Gomez Deck


>On Wed, 16 Oct 2002, [ISO-8859-1] Göran Hultgren wrote:
>
>> Ok, what about all you other people out there? Are my explanations making any
>> sense? Henrik - could you please acknowledge that I haven't made any gross
>> factual errors? Daniel, what do you think?
>>
>> I continue to stand by the Modules codebase as a good start, but I am always
>> open for improvements.
>
>It seems to me that part of the problem with these discussions of modules
>is that nobody has been terribly clear about what they hope to get out of
>them.  Perhaps if we make our goals clearer, it will be easier to talk
>about the possible solutions.  Here are a few things that I would think a
>module system might provide:
>
>1. A way to specify related pieces of code.  This has to
>include both entirely new classes and patches/additions to existing
>classes.  Let's call these "packages".
>2. A way to easily save and load these packages to and from easily
>distributable files.
>3. A way to cleanly update an image with a new version of a package.
>4. A way to cleanly unload a package from an image.
>5. A way to analyze dependencies between packages.
>6. A way to specify dependencies between packages.
>7. A way to protect packages from name clashes.
>8. A way to organize packages hierarchically.
>
>IMO, 1-3 are the most important.  Not surprisingly, these are also what
>DVS mostly provides, although it works better for straight additions to
>existing classes than for patches to them.  The interesting thing is that
>this can be provided without any changes to the base image, as a simple
>addon package.
>
>4, I think, could also be done fairly easily on top of 3.2, but it seems
>much less important to me: once I've loaded something into an image I
>rarely want to remove it.  If I'm testing a new package, I use a throwaway
>image.  I guess that assumes a minimal base image to load things into.
>
>Daniel has already done 5, again in 3.2.  I don't see why 6 would be very
>difficult - it ties into what Daniel and I were talking about with
>subclasses of Module to store metadata.  6 also seems like something that
>SqueakMap might be extended to do.
>
>7 is, of course, the big one: it is the real justification, as far as I'm
>concerned, of the work that's beem put into 3.3a.  But how big a deal is
>it?  Are people routinely struggling with naming conflicts?  I tend to
>throw a 2 letter prefix in front of my class names and forget about it.
>But maybe that's just me.
>
>8 would be nice, but the major benefits (being able to load/unload groups
>of packages at once) can be gotten through dependecies + dummy packages,
>the same way most of the linux packaging systems work.
>
>This is a highly personal take on things, of course - I'm not
>pretending that these preferences will be the same for everyone.  I'd
>be curious to hear what, for example, Stef's or Henrik's version of
>this list would look like.  But me, I'd rather see a lightweight module
>system in 3.2 without namespaces or hierarchy get widely used first, and
>then start to think about the full Module system a la 3.3a.
>
>Avi