Re: [Pyobjc-dev] unbound methods

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

On Wednesday, Jan 1, 2003, at 04:27 US/Eastern, Ronald Oussoren wrote:
> On Tuesday, Dec 31, 2002, at 17:34 Europe/Amsterdam, bb...@ma... 
> wrote:
>> On Monday, Dec 23, 2002, at 14:30 US/Eastern, Ronald Oussoren wrote:
....
> That would be nice, but not possible. It might be possible to get 
> 'Foo.foo(Foo)' working if the class method has the same signature as 
> the instance method, but that wouldn't allow overriding the class 
> method in subclasses. But all is not lost, read on ;-)
>
>>
>> ... and call the class method.  Or, maybe, you want to do...
>>
>>     Foo.foo_(aFoo)
> That would be [aFoo foo:] in Objective-C ;-). More seriously, that 
> wouldn't be usefull because the Python runtime looks for 'Foo.foo' 
> when you do 'aFoo.foo()'. This is what is causing us problems here.

No-- the intention would be that that would be the invocation of the 
Class method foo_ with aFoo as the single argument [and the Class 
object as 'self'].

>> ... where you are calling the class method and passing an instance as 
>> the argument?
>>
>> This isn't terribly clear, but I'm hoping it gets across the general 
>> idea that we should be able to support both class and instance 
>> methods that are named the same....
>>
>> One possibility would be to pass a kv argument that indicates that 
>> the class implementation should be used if there is both a class and 
>> an instance version-- i.e. Foo.foo(aFoo, useClassMethod=1)?
>>
>> But that would not allow an unbound version of the method to be 
>> obtained that is explicitly tied to class or instance...?
>
> We could mangle names of class methods, either by having a magic class 
> property for accessing class methods or by adding a prefix/postfix to 
> the methodname:
>
> * Foo.__clsmeth__.foo()
> * Foo._cls_foo()
> * Foo.foo_cls()
>
> I'd prefer the middle one given a suitable prefix: short, easily 
> remembered and not likely to ever be used as the prefix of an 
> Objective-C selector. If we go this route we should keep supporting 
> the current behaviour; NSArray.arrayWithArray_ should not be renamed 
> to NSArray._cls_arrayWithArray_, that would just be confusing. I'm not 
> sure wether we should support both naming schemes for class methods 
> that don't conflict with instance methods.

I agree that the current behavior should remain unchanged.  Rarely does 
the developer need to grab anything but a reference to the instance 
method.

In the ObjC context, we would implement something like:

- (IMP)methodForSelector:(SEL)aSelector;
+ (IMP)instanceMethodForSelector:(SEL)aSelector;

Where the first returns an instance method if invoked on an instance 
and a class method if invoked on a class (a Class object really being 
an instance of the meta object class).   The second method allows one 
to grab a reference to in instance method from a Class object.

Not very pythonic....

In the context of python, I like the idea of shoving the 'I really do 
want the class method' functionality into a "special" attribute.  It 
makes the code more readable than having to special case a prefix and 
ensures that there is no chance of namespace collision or ambiguity in 
the future.

Sure, a few more keystrokes, but that is a small price to pay to ensure 
that the code remain readable, thereby reducing confusion in a 
situation that will be used relatively infrequently but, when used, 
could confuse the heck out of a newbie.

I.e.:

NSObject.__class_methods__.description
NSObject.__instance_methods__.description

x = NSObject.new()
x.__class__.__class_methods__.description
x.__class__.__instance_methods__.description

This could be extended to provide:

x.__class__.__instance_variables__
x.__class__.__protocols__