Re: [Pyobjc-dev] posing

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

On Monday, Jan 20, 2003, at 01:37 US/Eastern, Ronald Oussoren wrote:
>> The pyobj_ivar contains a reference to the Python instance that 
>> effectively provides the Python side of the implementation of the 
>> current class;  not just a binding to the class, but also to the 
>> instance on the python side.
>
> I thought you found a clever way around this. Sorry about not 
> mentioning this before. You could of course store the reference to the 
> python instance in an NSHashTable, but that would probably have a 
> negative impact on performance.

Only per-class, which was what I was assuming would be all that was 
necessary.

I'm not exactly sure how to proceed from here -- see below.

>> OK.
>>
>> That makes life a bit more difficult, but I *really* want posing to 
>> work and, afaict, that instance variable is the only thing that is 
>> holding this back.
>>
>> But this also raises a question regarding the eventual implementation 
>> of categories.  Sort of.   With Categories, one needs to add Python 
>> implemented methods to an already existing class.
>>
>> Rephrase:  Categories and posing are effectively the same problem:   
>> they both imply that a class will preexist and that the category (or 
>> posing class) will not add any instance variables within its 
>> declaration.
>
> With libFFI it is possible to implement categories without adding an 
> instance variable. One of the features of libFFI is the possibility to 
> define closures that look like normal functions. A method in a 
> categorie can be implemented using a closure that contains a reference 
> to the python function implementing the method.
> The same trick could be used for mixed classes: 
> __pyobjc_pythonImplementation__ would also be a closure.

There are three problems that need to be solved:   categories, posing, 
and subclassing.

Posing is really just a special form of subclassing.

It sounds like Categories are nailed w/libFFI.   Have you made any 
progress on some kind of a tarball that contains the necessary bits of 
libFFI such that we can move to libFFI across the boards?

Subclassing currently works but has a "fatal" flaw in the context of 
posing:  subclasses currently require an instance variable.

At runtime, posing acts in a similar fashion as to categories.  Sort 
of.  When class B is posed as class A, class A is effectively renamed 
to %A and class B is renamed to A (actually, class B's definition is 
duplicated and the duplicate is marked as class A).    The effect is 
that the methods of class B are now implemented on class A.   Any 
overridden methods on the original class A (now %A) can be access by 
the methods that came from class B (now class A) by invoking [super ... 
over ridden method ...].

So, how to eliminate the required instance variable from the current 
implementation?

A Hash, as Ronald mentioned, would both solve the problem and likely 
introduce a significant performance hit.

However, if __pyobjc_pythonImplementation__ can be a closure (is that a 
noun?), then the instance variable should be able to be eliminated?

It looks like I need to move to the FFI build of PyObjC sooner rather 
than later -- it sounds like this change is going to require FFI's 
support for closures (or some other solution of a similar nature).

b.bum