ducasse <ducasse at iam.unibe.ch> wrote:
> >>>> So the natural follow up would be to go in the direction of
> >>>> 	- having a run-time package knowing its class and methods
> >>>
> >>> Eh, PIs do that, right?
> >>>
> >>
> >> No it queries the system organization this is different (ask avi if 
> >> you chat with him).
> >
> > Well, let me play devil's advocate here a bit.  PI defines a packaging 
> > semantics where the package a particular class or method is in, is 
> > defined by the system organization.  So, under the PI definition of 
> > "package", Göran is correct.  Now, you may prefer a different 
> > semantics for the package system (for example, so that you can have 
> > classes from multiple packages within one system category), but that's 
> > a separate issue.
> 
>   My point (and you know it but play the devil advocate if this is fun 
> for you) is that the mid-term solution is to stop to rely on category 
> conventions and have a real object as package entities.
> 
> Goran about your static script: what is the difference between a static 
> script and a bundle of package?
> For example
> SteApp1.2
> 	is composed of packages
> 		MW3.2
> 		TurtleEnvironment10.3
> 
> ....
> So is a script a separate entity, is it a composite? why and what are 
> the pros and cons?
> I'm a bit afraid to have yet another entity: package, SMpackage, 
> Script...

Ok, let me give this a few seconds. We have "load sripts" *today*. They
are simply packages on SM consisting of a .st filein that uses SM to
install other packages. Like this:

SMSqueakMap default installPackageWithId: '123-123-123-123-213'

BUT... as you can see the above line does not specify the *version*
(release) of the package - because SM1.x only knows about the *latest*
version. This makes all load scripts to this day so called "dynamic" -
they produce different results depending on when they are installed.

In SM2 you can write:

SMSqueakMap default installPackageReleaseWithId: '123-123-123-123-213'


...and in other ways to. But this time a specific *release* is specified
so the script will load the exact same file every time. As long as the
maintainer doesn't *change* that file of course. 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. Is that right? In that
case I *do NOT want them*. :)

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*.

regards, Göran