Monticello and PackageInfo
Locked
12
12
 
|
Dear all
[Squeak 4.4] I just found that Monticello injects #workingCopy into Class like this Class>>#workingCopy ^ self packageInfo workingCopy However, #workingCopy is defined neither on Class/Behavior etc nor on Object. What was the intended behavior? Best -Tobias |
Re: Monticello and PackageInfo
|
|
On 2 April 2013 10:38, Tobias Pape <[hidden email]> wrote:
> Dear all > > [Squeak 4.4] > I just found that Monticello injects #workingCopy into Class > like this > > Class>>#workingCopy > > ^ self packageInfo workingCopy > > However, #workingCopy is defined neither on Class/Behavior etc nor > on Object. What was the intended behavior? Do you mean #packageInfo instead of #workingCopy? frank > Best > -Tobias > > |
|
|
Am 02.04.2013 um 12:51 schrieb Frank Shearar <[hidden email]>:
> On 2 April 2013 10:38, Tobias Pape <[hidden email]> wrote: >> Dear all >> >> [Squeak 4.4] >> I just found that Monticello injects #workingCopy into Class >> like this >> >> Class>>#workingCopy >> >> ^ self packageInfo workingCopy >> >> However, #workingCopy is defined neither on Class/Behavior etc nor >> on Object. What was the intended behavior? > > Do you mean #packageInfo instead of #workingCopy? yes Best -Tobias |
Re: Monticello and PackageInfo
|
|
Did you get your question answered? If not, please clarify.. On Tue, Apr 2, 2013 at 6:33 AM, Tobias Pape <[hidden email]> wrote: Am 02.04.2013 um 12:51 schrieb Frank Shearar <[hidden email]>: |
Re: Monticello and PackageInfo
|
In reply to this post by Tobias Pape
You mean "String workingCopy" throws a DNU but should not?
-- Marcel |
Re: Monticello and PackageInfo
|
|
Looks like it got broken sometime during the 4.4 release.. On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel <[hidden email]> wrote: You mean "String workingCopy" throws a DNU but should not? |
Re: Monticello and PackageInfo
|
|
In reply to this post by marcel.taeumel (old)
That works in 4.3, but not 4.4. On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel <[hidden email]> wrote: You mean "String workingCopy" throws a DNU but should not? |
|
|
In reply to this post by Chris Muller-3
Hey Chris, hey list
Am 02.04.2013 um 19:51 schrieb Chris Muller <[hidden email]>: > Did you get your question answered? If not, please clarify.. No I did not. Suppose, you execute TestRunner workingCopy you get a NMU of TestRunner class dNU #packageInfo The same holds for MethodReference: (MethodReference class: TestRunner selector: #runAll) workingCopy #workingCopy is injected by the Monticello Package. My Question: Is the relatively new (2011) #workingCopy on Class and MethodReference just implemented wrongly or is something wrong with PackageInfo? Best -Tobias |
|
|
In reply to this post by Chris Muller-3
Am 03.04.2013 um 03:05 schrieb Chris Muller <[hidden email]>:
> That works in 4.3, but not 4.4. > > > On Tue, Apr 2, 2013 at 2:07 PM, Marcel Taeumel <[hidden email]> wrote: > You mean "String workingCopy" throws a DNU but should not? > > -- Marcel I have 'bisected' and the #workingCopy was introduced in 2011: Name: Monticello-cmm.436 Time: 10 March 2011, 1:46:11.144 pm - Added several methods for tracing MethodReferences and Classes back to their MC counterparts; their #workingCopy, and #repositoryGroup. - Ability to convert MethodReferences to equivalent MCMethodDefinitions, and classes to MCClassDefinitions. - Added MCRepository>>allVersionsDo:. Chris, what PackageInfo do you have that injects #packageInfo into Class and MethodReference? I've looked in several images and repositories and cannot find a PackageInfo that provides those :/ Best -Tobias |
Re: Monticello and PackageInfo
|
|
Hi Tobias, ok, I understand what you mean by "injected" -- you mean "extended". :) When a package adds a method to a class defined in another package, the first is said to "extend" the second. I looked more closely and found that I have extended Class with the following method: packageInfo ^ PackageInfo allPackages
detect: [ : each | each includesClass: self ] ifNone: [ nil ] We should include this in the base image.
Also #workingCopy should be changed to handle the possibility of it returning nil. On Wed, Apr 3, 2013 at 1:28 AM, Tobias Pape <[hidden email]> wrote: Am 03.04.2013 um 03:05 schrieb Chris Muller <[hidden email]>: |
Re: Monticello and PackageInfo
|
|
I think we should rather add this code:
Class>>packageInfo ^ PackageOrganizer default packageOfClass: self Best, Marcel |
Re: Monticello and PackageInfo
|
|
In reply to this post by Tobias Pape
On 02.04.2013, at 22:46, Tobias Pape <[hidden email]> wrote:
> Hey Chris, hey list > > Am 02.04.2013 um 19:51 schrieb Chris Muller <[hidden email]>: > >> Did you get your question answered? If not, please clarify.. > > No I did not. > > Suppose, you execute > TestRunner workingCopy > you get a NMU of TestRunner class dNU #packageInfo > > The same holds for MethodReference: > (MethodReference > class: TestRunner > selector: #runAll) workingCopy > > #workingCopy is injected by the Monticello Package. > > My Question: > > Is the relatively new (2011) #workingCopy on Class and MethodReference > just implemented wrongly or is something wrong with PackageInfo? > > Best > -Tobias This "feature" is misguided because a class can belong to multiple packages. So asking a class for its single package info is wrong. IMNSHO the #workingCopy method should be removed. It's not used in the system yet, fortunately. - Bert - |
Re: Monticello and PackageInfo
|
|
In reply to this post by Chris Muller-3
On 03.04.2013, at 07:40, Chris Muller <[hidden email]> wrote:
Either the methods should be removed (my preference), or be changed to return collections, to account for the possibility of having zero, one, or more package infos / working copies / repositories. - Bert -
|
Re: Monticello and PackageInfo
|
|
In reply to this post by Bert Freudenberg
> 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?) A class can only be defined in one package, 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? > 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. |
Re: Monticello and PackageInfo
|
|
On Wed, Apr 3, 2013 at 11:37 AM, Chris Muller <[hidden email]> wrote:
A class *can* be part of multiple packages. Imagine you have two packages, 'Foo' and 'Foo-Bar'. All the classes that belong to 'Foo-Bar' are also part of 'Foo'.
Colin |
Re: Monticello and PackageInfo
|
|
Doing that causes issues and confusion -- for example changing a
method in the Foo-Bar package means both the Foo package and Foo-Bar packages are dirty. By my understanding this is why most folks append suffixes to their package names like "-Core". That way, you have "Foo-Core" and "Foo-Bar" and "Foo-UI", etc. Three packages, no overlap, no ambiguity. Simple. Do we have any examples today of methods/classes belonging to multiple packages today? On Wed, Apr 3, 2013 at 2:01 PM, Colin Putney <[hidden email]> wrote: > > > > On Wed, Apr 3, 2013 at 11:37 AM, Chris Muller <[hidden email]> 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?) A class can only be defined in one package, >> 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 *can* be part of multiple packages. > > Imagine you have two packages, 'Foo' and 'Foo-Bar'. All the classes that > belong to 'Foo-Bar' are also part of 'Foo'. > > Colin > > > |
Re: Monticello and PackageInfo
|
|
In reply to this post by Chris Muller-3
On 03.04.2013, at 11:37, Chris Muller <[hidden email]> 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. > 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 - |
Re: Monticello and PackageInfo
|
|
In reply to this post by Chris Muller-3
On 03.04.2013, at 12:07, Chris Muller <[hidden email]> wrote: > Doing that causes issues and confusion -- for example changing a > method in the Foo-Bar package means both the Foo package and Foo-Bar > packages are dirty. > > By my understanding this is why most folks append suffixes to their > package names like "-Core". That way, you have "Foo-Core" and > "Foo-Bar" and "Foo-UI", etc. Three packages, no overlap, no > ambiguity. Simple. > > Do we have any examples today of methods/classes belonging to multiple > packages today? Yes. E.g., there are some projects that provide both separate "hyphen-packages" and one "combined" package. The former is better for development, the latter simpler for users. Balloon3D is an example. Also, OMeta uses custom package infos for bootstrapping. You have two package infos for the very same classes and methods. - Bert - > On Wed, Apr 3, 2013 at 2:01 PM, Colin Putney <[hidden email]> wrote: >> >> >> >> On Wed, Apr 3, 2013 at 11:37 AM, Chris Muller <[hidden email]> 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?) A class can only be defined in one package, >>> 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 *can* be part of multiple packages. >> >> Imagine you have two packages, 'Foo' and 'Foo-Bar'. All the classes that >> belong to 'Foo-Bar' are also part of 'Foo'. >> >> Colin >> >> >> > |
Re: Monticello and PackageInfo
|
|
In reply to this post by Bert Freudenberg
On Wed, Apr 3, 2013 at 2:07 PM, Bert Freudenberg <[hidden email]> wrote:
> > On 03.04.2013, at 11:37, Chris Muller <[hidden email]> 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 - > > > |
Re: Monticello and PackageInfo
|
|
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 <[hidden email]> wrote: > On Wed, Apr 3, 2013 at 2:07 PM, Bert Freudenberg <[hidden email]> wrote: >> >> On 03.04.2013, at 11:37, Chris Muller <[hidden email]> 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 - >> >> >> |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |