Hi Bert,

Thanks for your answer. See my comments below.

Am 01.11.2010 um 09:41 schrieb Bert Freudenberg:
> 2010/10/31 Bernhard Pieber <bernhard at pieber.com>:
>> The reason is that PackageInfos can overlap. There is an obsolete PackageInfo named 'PackageInfo' and a PackageInfo named 'PackageInfo-Base' Monticello knows about.
>> 
>> The method PackageOrganizer>>packageOfClass:ifNone: does not deal with this potential overlapping. It just answers the obsolete one because it comes first in its list of packages.
> That seems to be a bug, all code should iterate through all packages a class belongs to. E.g., Monticello does.
OK. But what would be a good way to fix the bug? Should the messages #packageOfClass: and #packageOfClass:ifNone: be there at all? In the trunk they are only used by the DependencyBrowser and PackageDependendyTest.

With overlaps one could have #packagesOfClass: and #packagesOfClass:ifEmpty: instead. But how would the PackageDependencyTest be written with those? E.g. with the overlapping packages PackageInfo and PackageInfo-Base, which one should e.g. Monticello depend on? Or should it depende both of them?

>> IMO the overlapping should be regarded as an error because it will probably lead to a lot of unintended side effects. Does anyone know a good reason for allowing overlapping PackageInfos?
> PackageInfo was designed to be universal. It is an arbitrary collection of classes and methods. It is not a partitioning - this is only how we use it in trunk with Monticello. But neither PackageInfo nor Monticello enforces that. Overlaps are perfectly normal even though we do not use them in the trunk process.
I am still skeptical that overlaps are worth the additional complexity and potiential confusion they cause, especially as in the trunk process we use packages to achieve a partioning. IMHO it is very easy to introduce subtle bugs by writing code based on the partioning assumption like the above example. Has someone ever used overlapping packages? If yes, for what exaclty?

As a compromise one could imagine a code layer above PackageInfo and Monticello which introduces the partitioning assumption and associated APIs like #packageOfClass: which could be used for the DependencyBrowser and the PackageDependencyTest. But that would add even more complexity. What do you think?

Cheers,
Bernhard