Re: [Pyobjc-dev] posing

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

On Monday, Jan 20, 2003, at 15:19 Europe/Amsterdam, bb...@ma... wrote:

> 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.
Its per instance: the instance variable that's added in class-builder.m 
contains a reference to the python half of the mixed class.

>
> 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.
Is it? IMHO it is not. Posing is a way to "trick" the runtime into 
using your class instead of the real class when performing 
objc_lookUpClass.

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

Yes, I have the tarball on my machine but cannot add it to the files 
section at SF (not enough permissions to add a new section). The 
tarball contains libffi from the GCC CVS HEAD of yesterday evening, 
plus some additional files that were needed to build it (and a 
modification of configure and Makefile.in to teach it to use these 
files).

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

closure is a non, but now that I think of it 
__pyobc_pythonImplementation__ cannot be a closure: It needs act like 
an instance variable :-(.
Ronald