Modules (was Re: Squeak Starter)

Stephane Ducasse squeak-dev at lists.squeakfoundation.org
Wed Oct 16 22:15:47 UTC 2002


Hi avi

I mainly agree with you. For me I do not want higher order modules in=
=20
Squeak. I would like
to have a good way of handling together classes and changes in logica=
l=20
group with dependencies.
I think that the modules of henrik could cover that. I'm not against=
=20
having namespace there.
Some people claim that packages and namespace should be orthogonal.=
=20
They are certainly right but I could
really live with that.

What I would like is **any** system that helps me managing my work an=
d=20
the dependencies between the
stuff I have. If the system could perform some analysis indicating th=
at=20
I will crash my system this would be great
(I accept reflective thing breaking but not simple: this class is not=
=20
present what do I do).
Then I would like to see how squeak can be cut into piece so that I d=
o=20
not have to
have sound and etoy if I do not need it. For me modules or packages=
=20
should be a way to realize
distributed development and to help the multiple head that squeak cou=
ld=20
have to grow (we could have
mini squeak, etoy squeak, sqScript all based on the same VM and core=
=20
and load the other on wish).

They should also help SqCentral people to focus on their business and=
=20
not cleaning and checking that
the parts of the system do not desaggregate.

So I think that we have the same wishes. A simple tool to control=
=20
complexity.

Stef

On mercredi, octobre 16, 2002, at 10:04  pm, Avi Bryant wrote:

>
> On Wed, 16 Oct 2002, [ISO-8859-1] G=F6ran Hultgren wrote:
>
>> Ok, what about all you other people out there? Are my explanations=
=20
>> making any
>> sense? Henrik - could you please acknowledge that I haven't made a=
ny=20
>> gross
>> factual errors? Daniel, what do you think?
>>
>> I continue to stand by the Modules codebase as a good start, but I=
 am=20
>> always
>> open for improvements.
>
> It seems to me that part of the problem with these discussions of=
=20
> modules
> is that nobody has been terribly clear about what they hope to get =
out=20
> of
> them.  Perhaps if we make our goals clearer, it will be easier to t=
alk
> about the possible solutions.  Here are a few things that I would=
=20
> 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 addition=
s to
> existing classes than for patches to them.  The interesting thing i=
s=20
> that
> this can be provided without any changes to the base image, as a si=
mple
> addon package.
>
> 4, I think, could also be done fairly easily on top of 3.2, but it=
=20
> 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=
=20
> throwaway
> image.  I guess that assumes a minimal base image to load things in=
to.
>
> Daniel has already done 5, again in 3.2.  I don't see why 6 would b=
e=20
> very
> difficult - it ties into what Daniel and I were talking about with
> subclasses of Module to store metadata.  6 also seems like somethin=
g=20
> that
> SqueakMap might be extended to do.
>
> 7 is, of course, the big one: it is the real justification, as far =
as=20
> I'm
> concerned, of the work that's beem put into 3.3a.  But how big a de=
al=20
> 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=
=20
> groups
> of packages at once) can be gotten through dependecies + dummy=20
> 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 mo=
dule
> system in 3.2 without namespaces or hierarchy get widely used first=
,=20
> and
> then start to think about the full Module system a la 3.3a.
>
> Avi
>
>
>
Dr. St=E9phane DUCASSE (ducasse at iam.unibe.ch)=20
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes





More information about the Squeak-dev mailing list