Le 5 juil. 2011 à 22:19, Niels Grewe a écrit :
> On Mon, Jul 04, 2011 at 05:52:29PM +0200, Quentin Mathé wrote:
>> Le 6 mai 2011 à 20:33, Niels Grewe a écrit :
>>
>>> On Fri, May 06, 2011 at 06:33:22PM +0200, Quentin Mathé wrote:
>>>> Do you have an idea to get this working on both Mac OS X and GNUstep in
>>>> the same correct way?
>>>
>>> I had another look and I think I know what the problem is. In
>>> -primitiveMethodSignatureForSelector: (line 1036), we are calling
>>> +instanceMethodSignatureForSelector: on NSObject. Hence, the method
>>> declared on ETCollectionMutationFilterProxy is not considered.
>>>
>>> So the funny question is not why it doesn't work on OS X, but why it
>>> works on GNUstep. Or rather, why it did work, because the empty
>>> collection test is failing for me with a fresh checkout.
>>
>> I finally worked out a fix for this issue. I was hoping to figure out a
>> better solution than a category on NSObject, but it's more tricky than I
>> expected as explained in the code comment.
>> See http://svn.gna.org/viewcvs/etoile?rev=7064&view=rev
>
> Okay, now I can see what's going on here. Using the category should be
> fine, but I wonder whether we could get away with calling
> class_getInstanceMethod() and method_getTypeEncoding() instead (which is
> what NSObject's +instanceMethodSignatureForSelector: will do anyways).
Right, that's a good point.
I'm getting a bit lazy right now, so I'll let it as is for this release.
>> The thing I don't understand though is why the method body is not empty for
>>
>> - (uintptr_t)pointerSizedProxyNull
>> {
>> if ([collection isEmpty])
>> {
>> return 0;
>> }
>> NSInvocation *inv = [NSInvocation invocationWithTarget: self selector:
>> _cmd arguments: nil];
>> uintptr_t retValue = 0;
>>
>> [self forwardInvocation: inv];
>> [inv getReturnValue: &retValue];
>> return retValue;
>> }
>>
>> Because when I run the test suite, this code is never executed.
>
> If I recall correctly, the purpose of this is to allow
> -pointerSizedProxyNull to be send to the members of the collection as
> the payload message of a higher-order message.
ok I see.
> But I have to admit that
> the chances of anybody implementing a method of that name are quite low.
Indeed ;-)
I'd be in favor of removing it then.
Cheers,
Quentin.
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
