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

[Ronald O. <ous...@ci...>]

On 9 nov 2003, at 0:30, Jack Jansen wrote:

>
> On 7-nov-03, at 18:45, b.bum wrote:
>
>> 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.
>
> This hits the two-faced issue on the head: it's a bug if you look at 
> this with ObjC in mind, it's an essential shortcoming if you look at 
> it with Python in mind.
>
> Bob said (at some point in the past of this discussion) something to 
> the effect that someclass.somemehod is a selector. If you view it from 
> that angle then the current behavior is a bug.
> My initial thought (with my Python hat on) was that 
> someclass.somemethod is either a class method or an unbounded instance 
> method. Then this isn't a bug but a shortcoming that can't be 
> overcome.

That's a nice summary of the issues.

Having thought about this a little I wouldn't mind if we changed the 
selector code to be smarter about this, e.g.:

1) If the method is accessed through an instance it is always an 
instance method (and if there is only a class method we raise an 
AttributeError)
2) If the method is accessed through a class it is:
    - an unbound method if it is only an instance method
    - a bound method if it is only a class method
    - a "smart" method if it is both an instance method and a class 
method

Smart methods somehow detect how they are used (the number of arguments 
passed in springs to mind, if you call an unbound instance method you 
pass the self argument, if you call a bound class method you don't).

Other issues:
- if the class method has a different signature than the instance 
method we cannot create a "smart" method, I'd fall back to the current 
behaviour (e.g. return the instance method). It is highly unlikely that 
this ever happens.
- It *must* be possible to get information about instance methods 
through the class, otherwise we cannot create class browsers.
- If a "smart" method is overridden in a subclass, the subclass should 
still contain a "smart" method.

Ronald