Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

[b.bum <bb...@ma...>]

On Nov 7, 2003, at 8:20 AM, Bob Ippolito wrote:
> No, it also happens when you are just using ObjC classes from the 
> Python side of the bridge.  It *always* binds to the instance method, 
> nomatter what, if it has one.  I'm not even worried about overriding 
> them from Python at the moment, just making ObjC classes usable as 
> they should be.

Right -- and that is a bug.

"Binding" shouldn't occur until invocation except in the case where the 
developer has explicitly invoked method via the unbound method 
mechanism where they previously obtained a reference to the instance or 
class version of a method.

I.e. if I have...

id foo;

foo = ... something ...;
[foo performSelector: @selector(description)];

... then the class or instance version of description will be invoked 
depending on if foo is a class or instance object.

>> I.e. if you do Foo.description to grab a reference to the description 
>> method of the Foo class--  which has both +description and 
>> -description-- then we should be able to figure out if the class or 
>> instance implementation should be invoked at the time of dispatch 
>> based on what the target of the invocation is.
>>
>> There are other details that would have to be worked out.  But, for 
>> the most part, it would seem that this could be done in a largely 
>> automatic and transparent fashion.   The remaining unknowns are 
>> largely arbitrary in nature because they only occur due to the 
>> combined interaction of the ObjC and Python runtimes -- we are free 
>> to do whatever we want.
>
> That's what I was proposing, however there is some ambiguity in 
> determining the target of the invocation if and only if we allow 
> SomeClass.instanceMethod(someInstance) -- but I proposed a way that 
> would figure that out most of the time, by counting the number of 
> arguments given if that selector exists for both the class and the 
> instance, which should work in every case that doesn't use varargs (do 
> any?).

If someInstance is an instance method, then the instance implementation 
should be used... if it is a class method, then use the class 
implementation.   This most closely mimics the ObjC runtime.

If the developer specifically wants the class vs. instance version of 
the method, then we should add API for querying for the one versus the 
other.   The API already exists on NSObject.

b.bum