Bug in PackageInfo?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in PackageInfo?

Alexandre Bergel-2
Hello,

I am currently working on an extension of OB to have a package/
hierarchy button in the browser (like in Visualworks). However, I  
found some strange behavior in PackageInfo. I attached a small .cs to  
this email that contains the following test:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
        cls := self dummyClass.
        cls compile: 'zork ^ 5' classified: ('*', self dummyPackageName).
        cls compile: 'foo ^ 10' classified: '*MyStupidPackage1'.
        cls compile: 'bar ^ self foo' classified: '*MyStupidPackage2'.
        cls compile: 'barbar ^ self foo' classified: '*MyStupidPackage2-test'.
       
        p1 := PackageInfo named: 'MyStupidPackage1'.
        p2 := PackageInfo named: 'MyStupidPackage2'.
        p3 := PackageInfo named: 'MyStupidPackage2-test'.

"BREAK HERE"
        self assert: (p2 == p3).
               
        self assert: (self dummyPackage coreMethods asSet =  {(cls>>#zork)  
methodReference} asSet).
        self assert: ((p1 coreMethodsForClass: cls) asSet = {(cls>>#foo)  
methodReference} asSet).

"SHOULD BARBAR BE INCLUDED OR NOT?"
        self assert: ((p2 coreMethodsForClass: cls) asSet =
                                {(cls>>#bar) methodReference . (cls>>#barbar) methodReference}  
asSet).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

It seems that (p2 == p3) should be true.
What the monticello team thinks ?
If it is a bug, I propose myself to fix it.

Regards,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






BugInPackageInfo.st (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug in PackageInfo?

Bert Freudenberg-3
Am 11.05.2006 um 17:08 schrieb Alexandre Bergel:

> p2 := PackageInfo named: 'MyStupidPackage2'.
> p3 := PackageInfo named: 'MyStupidPackage2-test'.
> self assert: (p2 == p3).
>
> It seems that (p2 == p3) should be true.

How could two packages with a different name be equal, let alone be  
identical?

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Bug in PackageInfo?

Markus Gälli-3

On May 11, 2006, at 5:55 PM, Bert Freudenberg wrote:

> Am 11.05.2006 um 17:08 schrieb Alexandre Bergel:
>
>> p2 := PackageInfo named: 'MyStupidPackage2'.
>> p3 := PackageInfo named: 'MyStupidPackage2-test'.
>> self assert: (p2 == p3).
>>
>> It seems that (p2 == p3) should be true.
>
> How could two packages with a different name be equal, let alone be  
> identical?
>
We might want to be able to ask if p2 includesPackage: p3 though. I  
think the answer should be true.
As far as I can see, this is not implemented yet, but should be "a  
piece of cake"...

Cheers,

Markus


Reply | Threaded
Open this post in threaded view
|

Re: Bug in PackageInfo?

Alexandre Bergel-2
In reply to this post by Bert Freudenberg-3
>> p2 := PackageInfo named: 'MyStupidPackage2'.
>> p3 := PackageInfo named: 'MyStupidPackage2-test'.
>> self assert: (p2 == p3).
>>
>> It seems that (p2 == p3) should be true.
> How could two packages with a different name be equal, let alone be  
> identical?

That's the question. Should 'test' be a package category or should it  
refer to a new package ?
This is not clear when reading the code of PackageInfo. For instance,  
let's assume that p2 ~~ p3, then

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
        cls compile: 'foo ^ 10' classified: '*MyStupidPackage1'.
        cls compile: 'bar ^ self foo' classified: '*MyStupidPackage2'.
        cls compile: 'barbar ^ self foo' classified: '*MyStupidPackage2-test'.
       
        p1 := PackageInfo named: 'MyStupidPackage1'.
        p2 := PackageInfo named: 'MyStupidPackage2'.
        p3 := PackageInfo named: 'MyStupidPackage2-test'.

"DO NOT BREAK ANYMORE"
        self assert: (p2 ~~ p3).
               
        self assert: (self dummyPackage coreMethods asSet =  {(cls>>#zork)  
methodReference} asSet).
        self assert: ((p1 coreMethodsForClass: cls) asSet = {(cls>>#foo)  
methodReference} asSet).

"BREAK HERE"
        self assert: ((p2 coreMethodsForClass: cls) asSet =
                                {(cls>>#bar) methodReference . (cls>>#barbar) methodReference}  
asSet).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

if p2 and p3 are two distinct packages, then the core methods of p2  
should not be the one of p3...

Cheers,
Alexandre

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.cs.tcd.ie/Alexandre.Bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.