Fix to PackageOrganizer>>packageOfClass:

> All,
>
> I was confused about the purpose of
> PackageInfo>>mostSpecificPackageOfMethod:ifNone: and
> PackageInfo>>mostSpecificPackageOfClass:ifNone:
>
> They seem to be a workaround to the bug that exist in
> #packageOfClass:ifNone: and #packageOfMethod:ifNone:?
>
> I propose this fix, after discussing it with Lukas:
> http://code.google.com/p/pharo/issues/detail?id=1752
>
> Background of problem:
>
> In theory it should not be possible for packages to overlap. Every
> class, and every method should belong to only one Category. In reality
> packaging bugs and other actions does cause packages to be created
> that overlap.
>
> An example in PharoCore, 10505 is this:
>
> (PackageOrganizer default packageNamed:  'Collections' ifAbsent: [
> self error: 'hmm']) includesClass: Text. " true "
> (PackageOrganizer default packageNamed:  'Collections-Text' ifAbsent:
> [ self error: 'hmm']) includesClass: Text. " also true! "
>
> In the old implementation, #packageOfClass: would have returned the
> first category that matches. It will now return the more specific
> 'Collections-Text'.
>
> I suggest that #mostSpecificPackageOfClass* and
> #mostSpecificPackageOfMethod* methods be removed as well?
>
> --
> Danie Roux *shuffle* Adore Unix - http://danieroux.com
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> On Thu, Jan 7, 2010 at 8:14 PM, Nicolas Cellier wrote:
>> Would it prevent merging squeak/trunk Collection ?
>> If yes, I suggest a status quo.
>
> No, I checked and could merge both ways (adding methods to Text on
> Squeak trunk, and Pharo, and "cherry-picking" them both ways).
>
> Monticello hangs on to the package name and index only by that - it
> does not infer it from the class or method.
>
> The same problem exists in my Squeak trunk image, btw. In this case
> only if the name of the shorter package is a symbol:
>
> (PackageOrganizer default packageNamed:  #OB ifAbsent: [ self error:
> 'hmm']) includesClass: OBMorphBuilder.
> (PackageOrganizer default packageNamed:  'OB-Morphic' ifAbsent: [ self
> error: 'hmm']) includesClass: OBMorphBuilder.
>
> I guess there is a biggest issue to be fixed here, namely the proper
> maintenance of "PackageOrganizer default packages" :-)

> 2010/1/7 Mariano Martinez Peck :
>> I think we should wrote somewhere how to submit an issue
>
> I followed http://code.google.com/p/pharo/wiki/HowToContribute :-)
> I missed the step to set the status to "Fixed" though.
>
>> it's name and the trick of the dirty packages...
>
> "The trick of the dirty packages". Sounds like a crime novel. But
> seriously, what is this trick?

> On Thu, Jan 7, 2010 at 8:55 PM, Danie Roux <[hidden email]> wrote:
>> On Thu, Jan 7, 2010 at 8:52 PM, Stéphane Ducasse wrote:
>>>> In the old implementation, #packageOfClass: would have returned the
>>>> first category that matches. It will now return the more specific
>>>> 'Collections-Text'.
>>>
>>> You mean with your fix?
>>
>> Yes, once that fix is applied it will return the more specific one. I
>> apologise for the confusion :-)
>
> May I be so bold to ask that this fix be integrated into the next
> batch? OB use #mostSpecificPackageOfClass and it would be better if is
> used #packageOfClass: instead. But then #packageOfClass: needs to have
> this fix of course :-)
>
> http://code.google.com/p/pharo/issues/detail?id=1752
>
> --
> Danie Roux *shuffle* Adore Unix - http://danieroux.com
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project