Help with PackageInfo-Base in inbox

Folks -

I need some help with the PackageInfo-Base submission in the inbox. I'm
simply uncertain if it is the correct implementation; it seems there is
a potential issue there as the test makes an override to the package the
method is defined in. This just smells funny and changing the way
overrides get dealt with sounds a recipe for disaster if it goes wrong.

Anyone up for checking the submission and giving it a thumbs up or down?

Cheers,
   - Andreas

On 2009-12-23, at 8:05 AM, Andreas Raab wrote:

> Folks -
>
> I need some help with the PackageInfo-Base submission in the inbox. I'm simply uncertain if it is the correct implementation; it seems there is a potential issue there as the test makes an override to the package the method is defined in. This just smells funny and changing the way overrides get dealt with sounds a recipe for disaster if it goes wrong.
>
> Anyone up for checking the submission and giving it a thumbs up or down?

Thumbs down, I say. It appears to reverse the meaning of overridden; ie, it causes #overriddenMethodsDo: to answer the methods it overrides in other packages, rather than the methods it contains which have been overridden by other packages.

Colin

Colin Putney wrote:
> On 2009-12-23, at 8:05 AM, Andreas Raab wrote:
>
>> Folks -
>>
>> I need some help with the PackageInfo-Base submission in the inbox. I'm simply uncertain if it is the correct implementation; it seems there is a potential issue there as the test makes an override to the package the method is defined in. This just smells funny and changing the way overrides get dealt with sounds a recipe for disaster if it goes wrong.
>>
>> Anyone up for checking the submission and giving it a thumbs up or down?
>
> Thumbs down, I say. It appears to reverse the meaning of overridden; ie, it causes #overriddenMethodsDo: to answer the methods it overrides in other packages, rather than the methods it contains which have been overridden by other packages.

Thanks. But ... how exactly is one supposed to know that?

Cheers,
   - Andreas

On 2009-12-23, at 9:47 AM, Andreas Raab wrote:

>>> Anyone up for checking the submission and giving it a thumbs up or down?
>> Thumbs down, I say. It appears to reverse the meaning of overridden; ie, it causes #overriddenMethodsDo: to answer the methods it overrides in other packages, rather than the methods it contains which have been overridden by other packages.
>
> Thanks. But ... how exactly is one supposed to know that?

Not sure I understand the question. Are you saying that the PackageInfo source is impenetrable? If so, I agree. The code is fairly well written, but ultimately it's a hack that has way, way outgrown its intended lifespan, and it can be kind of confusing. Or was there something more specific you wanted to know?

Colin

On 2009-12-23, at 9:47 AM, Andreas Raab wrote:

> Thanks. But ... how exactly is one supposed to know that?

I guess I should have gone into more detail. If you look at the implementation of #overriddenMethodsDo:, you'll see that it iterates over all the overridden methods in the image. The current version sends #isOverrideOfYourMethod: to find out if the method belongs to the package, but has been overridden by another package. See the implementation of #isOverrideOfYourMethod:. The proposed change instead sends #isYourClassExtension:, which effectively inverts the logic. Overridden methods will be in a category like *foo-overrides. This means the package foo is overriding some other package. #isYourClassExtension: will answer true when sent to package Foo, but not package Bar.

Make sense?

Colin