On Wed, Apr 3, 2013 at 2:07 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 03.04.2013, at 11:37, Chris Muller <asqueaker at gmail.com> wrote:
>
>>> This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong.
>>
>> (Why such strong words?)
>
> Sorry, I didn't want to sound offensive.
>
>> A class can only be defined in one package,
>
> That is exactly the misconception I wanted to point out.

Ok, lets talk specifics.  In a recent trunk image:

    Smalltalk allClasses select: [ : eachClass | (PackageInfo
allPackages count: [ : eachInfo | eachInfo includesClass: eachClass
])>1]

   ---> "{MCMockClassH . MCMockClassD . MCMockClassB . MCMockClassE .
MCMockClassA . MCMockASubclass . MCMockClassF . MCMockClassG .
MCMockClassI}"

Clearly, these "Mock" classes are a special case that occurs because,
back in 2004, Avi defined his own PackageInfo subclass (something you
once said you disagree with).  Even to this day, there is not
agreement about the semantics of PackageInfo but I'd bet we could find
a way to "fix" this special-case (not that anyone would notice even if
we didn't).

So, we don't have any good examples in the image, what is the reason
any external packages would want to do it?  You mentioned Balloon-3D
-- it happens our package is named "Balloon" why shouldn't it be
"Balloon-Core" and "Balloon-3D"?  I don't know about OMeta -- might be
another special-case..?  Why does it want a class to belong in two
PackageInfos?


>> just as in Monticello, and this method simply associates its MC
>> equivalent to PackageInfo domain objects.  Why do you say a class can
>> belong to multiple packages -- because of extensions?
>
> A class is included in all packages that answer true to includesClass:. For example, even with the default PackageInfo a class would be in both "Foo-Bar" and "Foo".
>
>>> IMNSHO the #workingCopy method should be removed. It's not used in the system yet, fortunately.
>>
>> It's used by external utilities for automating the building of .sar
>> packages which should be included in the system.
>
>
> As I wrote in the other message (too bad discussion threads are constantly broken), the code should be written to deal with zero, one, or more packages containing the class. Possibly it should raise an error if more than one package includes the class. Monticello itself avoids this problem by always starting from the package/working copy instead from a class, and IMHO this is a good general principle.
>
> - Bert -
>
>
>