Re: [Pyobjc-dev] Handling (void *)

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

[of course, in the immediate term, we should handle None passed to a 
(void *) argument as NULL and vice-versa -- this should be pretty easy 
and takes care of most situations as most callbacks really don't need 
callback information given that the callback method is executed in the 
same instance of the class that made the original call and, as such, 
all of the context is available to the developer anyway.]

On Friday, November 8, 2002, at 05:31 AM, Ronald Oussoren wrote:
> BTW. Jack's solution (None->nil, PyCObject->extract the pointer, ...) 
> is a better solution for almost anything with the possible exception 
> of the userInfo arguments in some Cocoa APIs. This does work correctly 
> with 'void*-as-pointer-to-block-of-memory'.

Why don't we simply limit the calls to methods that take context 
information to always taking an object reference?  This is what the 
Java Bridge does and, as much as modeling things after the Java bridge 
is typically a bad idea, it seems like a pretty reasonable solution.

In all cases, the context information is produced by the developer and 
subsequently consumed by the developer-- there is never a case where 
the AppKit manipulates the context data.   In general, the whole MVC 
design pattern will lead the developer to producing and consuming the 
context information within the same class.   While there could be the 
rare situation that the developer would produce a value in ObjC to be 
consumed in Python or vice-versa, this is easily addressed by simply 
providing cover in one language or the other to handle the conversion 
across the bridge, as necessary.

If we wanted to be particularly tricky, we could use a weak reference 
type scheme to create a map between (void *) values that were passed 
across and their corresponding Python object.   By maintaining two 
maps-- Python->ObjC and ObjC->Python-- we could actually map between 
the Python and ObjC objects as the bridge is crossed.   That is, a call 
that uses a Python encapsulated NSView reference would enter ObjC w/the 
context information being the (id) of the NSView instance.  Similarly, 
the call back into Python could map back from the NSView instance to 
the Python object.

As long as everything is maintained as weak references-- as straight 
maps mapping the addresses and nothing more-- this would even work if 
the developer passes something like [foo userContext: (void *) 1234] 
across the bridge.   The key is to make sure that the weak references 
are destroyed as the python objects are destroyed (not much we can do 
on the C side of the bridge-- but not much we need to do, I don't 
think).

--

This doesn't cover NSData, NSImage, and the handful-- very small 
handful-- of other cases where there is a (void *) method and there 
isn't some alternative API that can be used instead.   Those situations 
are somewhat of a per-context type issue;  i.e. we might need to create 
specific bridging functionality to support these classes.

b.bum


b.bum
Are you laughing?
	... they are.