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

[Bob I. <bo...@re...>]

On Nov 7, 2003, at 10:53 AM, b.bum wrote:

> Unless I'm missing something, can't we always tell at the moment of 
> dispatch whether or not a particular method should be resolved in the 
> class or instance context?
>
> When objc_msgSend() is invoked, the SEL parameter is resolved 
> internally based on the 'self' parameter -- on the target of 
> invocation.   So, once we have an object reference and a selector, our 
> bridged dispatch to the method IMP should "just work" regardless of 
> whether it is a class or instance.
>
> The only place that class vs. instance method is problematic would 
> appear to be within the Python subclasses of ObjC objects where there 
> is a need to define both a class and an instance method.  I.e. 
> +description vs. -description.

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.

> Given that +description requires, effectively, a redeclaration through 
> the use of selector(), we could change the name of the method 
> slightly-- and invisibly-- at that time.
>
> But that is ugly.
>
> Instead, can we handle this at the time of dispatch?

Sure, that's what I'm asking for :)

> 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?).

-bob