Stephan Rudlof <sr at evolgo.de> wrote:
> But I was talkin about "they had to give some hints about
> *** how compatible ***
> a package from one universe is in the other one" (see above!)...

Right, and I didn't disagree.  Someone, or at least some program, has to
do the work to determine that a new package can be used with the rest of
the packages in a universe.

I do disagree with calling this "mixing".  Once you figure out that it
is compatible, however that may be, you may as well add it into the
universe for real.


> > not about how you measure
> > it.  Instead of having an annotation on P that says "I seem to work in
> > A", you can simply add P to A.  This is a very important point.  It is
> > pretty much the definition of what a universe is.
> 
> OK.
> But you also have to add a compatibility measurement for each package
> version for each new universe (as you have stated below, too).


No, I said something different.  Once a package is in a universe it's in.
The auto installer can simply grab the most recent version of any requested
package, because by definition all the packages in the universe are mutually
compatible.

What I said was that *if* you want to do compatibility codes, then you need to
do them per-universe.


> > A third example would be if you remove a method that was deprecated in
> > 3.4.  That's completely backwards compatible in a 3.7-based universe,
> > because no one is calling the method any longer, but of course it breaks
> > compatibility in a 3.4-based universe.
> > 
> 
> Your examples are good for illustrating my original point.

I'm surprised.  Do you truly plan to have multiple sets of
compatibilities for each version of each package?  Goran's list of
questions made it sound like the questions are asked just once, not once
per universe.  Have you considered what the UI would be like?

As an extra challenge, realize that compatibility codes are not alone
in varying by universe.  Consider the properties of a package in
the universes prototype:

	name
	version
	description
	url
	dependsOn

Fully four out of five make sense to vary from universe to universe:
Names have different short forms, versions can be shortened as well, the
description can go into detail on different points due to having
different audiences read them, and dependsOn may need extra packages in
some universes (e.g., LargeLists being required in a 3.6-ish universe).



> > All of the above questions are easy if you know which universe you are
> > talking about, and unanswerable otherwise.  Thus, it seems that
> > compatibility codes should be associated with (universe,package) tuples,
> > not with bare packages.
> 
> Exactly (if packages are package versions/releases (I've been sloppy
> here above, too))!
> 
> But it is also possible to put these as (universeAttribute (e.g.
> Squeak3.7), package version (!), compatibility) tuples in one universe,
> isn't it?

I don't understand the question.  A universe, the way I've described it,
is a set of *packages*.  There should be more than one, and each image
will participate in exactly one.

You can, of course, implement a universe object in a variety of ways.
Pretty much anything that responds to #packageList will do.  It is worth
considering carefully what the purpose would be, however, and whether
a simple Set is not sufficient.


-Lex