[squeak-dev] Monticello and PackageInfo

Chris Muller asqueaker at gmail.com
Wed Apr 3 19:37:00 UTC 2013


If I'm asking why a class should belong in two PackageInfos it's only
fair I answer why it shouldn't:  Because by the PackageInfo domain
model mirroring MC's model, they are able to work together better.
For example, the use-case I cited previously was one-click building
.sar packages (MaSarPackage on SqueakMap).  Utilities like that are
much easier to build and maintain when the cardinalities between the
models match.

On Wed, Apr 3, 2013 at 2:18 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 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 -
>>
>>
>>


More information about the Squeak-dev mailing list