[TFNR][REPORT]Where are we?!

ducasse ducasse at iam.unibe.ch
Tue Nov 18 09:07:21 UTC 2003


>
> ...and in other ways to. But this time a specific *release* is 
> specified
> so the script will load the exact same file every time.

excellent. this was more than needed.

> As long as the
> maintainer doesn't *change* that file of course.

sure

>  I did think about
> immutability but after input from other prominent Squeakers have 
> decided
> to instead rely on people *not abusing this*.
>
> Ok, now back to your question - bundles. Using my intuition I guess 
> that
> a "bundle" is a file actually *containing* multiple packages instead of
> "referencing them" like the load script above.

Not necessary. Conceptually you can say that a bundle is composed of 
packages
but internally you can code that the way you want.

The advantage that composite gives you is a uniform interface to 
manipulate bundle/script
and package. There is a difference between concepts and implementation.

At the end you want to load an application (may be using a script but 
this is file oriented)
an object that knows how to build itself picking the right versions of 
his elements.

>  Is that right? In that
> case I *do NOT want them*. :)

I did not mean that.
>
> Because it goes straight against my coming plan for dependencies.
> Dependencies should IMHO be specified *outside* of the packages in the
> form of independent objects I like to call *package configurations*.

package configurations seems to me like envy config maps (apparently 
the problems
in envy config maps is that you could not reference to subapplication 
versions) but
I should ask joseph that kind of ugly envy stuff. your package 
configurations look also as bundle in VW.
I'm not expert in the fine pros and cons of both approaches but I hope 
you know them.

My point is that I already have my own script to rebuild my small 
system but we cannot ask every body to
rehack the same in his corner so any decent package mechanism has to 
have version identification and it should work well
else all our efforts to modularise squeak will fail. It was for example 
fun to see andreas wondering how
to be able to load old package in Squeak. There is a simple scalable 
solution to that problems: packages
with version and configuration you know that I'm sure.

So I'm waiting to see SM 2

regards, Göran
>




More information about the Squeak-dev mailing list