Re: NSLog(@"%@",[NSProxy class]);
Re: NSLog(@"%@",[NSProxy class]);
- Subject: Re: NSLog(@"%@",[NSProxy class]);
- From: Greg Herlihy <email@hidden>
- Date: Sat, 11 Mar 2006 16:30:54 -0800
- Thread-topic: NSLog(@"%@",[NSProxy class]);
NSProxy is not "broken". NSProxy happens to be an abstract class - which
means first - it must be subclassed before it can be used; and second -
there are certain methods which a subclass of NSProxy must implement. As it
happens, NSProxy has two such methods - methodSignatureForSelector is one of
them (forwardInvocation: is the other).
And in fact all that an NSProxy subclass's methodSignatureForSelector does
in most cases is simply to forward the call to the object being proxied
(stored as a "realObject" instance variable in the example below):
(NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
{
return [realObject methodSignatureForSelector:aSelector];
}
And all of this information about NSProxy is easily found in the Foundation
Reference for Objective-C documentation.
Greg
On 3/11/06 4:03 PM, "Philippe Mougin" <email@hidden> wrote:
> Agent M wrote:
>> I have come across a difficulty with an NSProxy subclass
>> on 10.3.9 which can be summed up with the following lines:
>>
>> Class p=[NSProxy class];
>> NSLog(@"class %@",p);
>>
>> The second line throws an exception:
>> *** Uncaught exception: <NSInvalidArgumentException>
>> *** -[NSProxy methodSignatureForSelector:] called!
>
> Actually this is a general problem. Briefly, the whole meta level of
> the NSProxy class hierarchy is broken, making the NSProxy class
> object non-functional. The problem comes from the fact that, in the
> current (broken) implementation, NSProxy's meta class inherits from
> the NSProxy class. This mimics the NSObject class system layout, but
> while this layout is correct for NSObject, it is not correct for
> NSProxy because of the differences in semantic between the concept of
> an object an the concept of a proxy.
>
> Executive summary: the NSProxy class object is broken. Do not use it,
> or write workarounds (like you did) to support the functionality you
> need.
>
> Best,
>
> Philippe Mougin
> http://www.fscript.org
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden