Julian Fitzell <julian at beta4.com> wrote:


> >>>
> >>> Let's say I have package 'A' and package 'B'. And I have a class that 
> >>> belongs to A *and* B. Where should I put it?
> >>>
> >>> My solution was to create a third package and add this as a 
> >>> prerequiste of A *and* B. Not a good solution if there is a more 
> >>> complex example.
> >>
> >>
> >>
> >> Why not?  Can you give me a more complex example where this wouldn't 
> >> be a good solution?
> > 
> > 
> > The 'bad' thing is, that there will be a throng of little prerequistes 
> > in a more complex example. OK, you could say I have to refactor the 
> > whole thing. But in my example I just wanted to extract a piece of code 
> > without changing the original package.
> 
> Well, I think you're write that refactoring is the correct solution in 
> the long run, but...


Right.  I am having a hard time grasping this situation as well.  In
particular I worry about what happens if the packaging infrastructure
*does* allow the same chunk of stuff to belong to multiple packages. 
What does this mean?  How do I deal with it as a developer trying to
work with these packages?

In general, a library or tool should not only have features, but
carefully considered limitations.  It is useful, for example, to know
that only methods may access instance variables.  It is probably a good
limitation that each program fragment (be it a class or a method or
whatever else) belongs to just one package.

Now, it is possible to allow two packages to overlap, and to have one
package give the true version of things whenever both are loaded.  You
know, like in Collage or PIE.  This may solve Chris's problem.  Does
Monticello allow it?  If it does not, it would be nice if it did.  

Another possible approach, is to use namespaces, and to have a separate
copy of the "shared" classes in each namespace.  Now they do not
interfere with each other.  I don't know how far along namespace usage
is in any of Squeak's package systems today.

All this said, I could well be wrong, and maybe it does make sense to
allow one program fragment to belong to multiple packages.  For now,
though, I don't understand what the semantics would be, and honestly I
admit I don't appreciate the motivation.  Hopefully one of the
approaches in the previous two paragraphs will work out?

-Lex