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

[Peter M. <zig...@po...>]

On Friday, November 8, 2002, at 05:41 PM, Ronald Oussoren wrote:

>
> On Thursday, Nov 7, 2002, at 17:12 Europe/Amsterdam, bb...@ma... 
> wrote:
>
>> That seems like about as close to a workable set of behaviors as we 
>> can get without special casing certain methods.   For contexts that 
>> use a (void *) as a bit of userInfo, we simply need to make sure that 
>> a Python object passed in can be recovered during the call back.
> I thought of an simpler way to "fix" this on the way home last night. 
> PyObjC has a mechanism to change the signatures of Objective-C methods 
> as seen from Python. We could use this to change all '(void*)userInfo' 
> arguments to '(int)userInfo' arguments. At the very least this allows 
> us to actually use these methods until we come up with a better 
> solution. If the userInfo will always be passed back to Python code 
> this is solution is good enough for me: Even if you wanted to pass a 
> python object you could stuff that Python object into a list and pass 
> the list index to the selector.
>
> This obviously is not the right fix in general (what if you want to 
> use an existing method that expects a pointer to some data).

So you think that we should treat (void*) as an integer rather than a 
pointer, right? That works for me but it does seem a bit inelegant.

Is there anything in python (2.2 onwards of course) that isn't an 
object? If not, I think we should consider (void *) to be synonymous 
with (id). The other use for (void*), as a pointer to block of memory 
(eg. write()), can't really be done in python without wrapping it in an 
object, right? So any API using (void *) for that purpose would need to 
be specially wrapped anyway. Am I wrong?

Peter