4 messages in net.java.dev.jna.usersRe: [jna-users] Returning Object type
FromSent OnAttachments
Duncan McGregorNov 15, 2007 11:14 am 
Timothy WallNov 15, 2007 11:40 am 
Timothy WallNov 15, 2007 11:49 am 
Duncan McGregorNov 16, 2007 1:39 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [jna-users] Returning Object typeActions...
From:Duncan McGregor (dun@oneeyedmen.com)
Date:Nov 16, 2007 1:39:36 pm
List:net.java.dev.jna.users

Thanks again Timothy. I've done as you suggested and created objc_msgSend variants with different return types, as it turns out that id sometimes means pass struct by value. I've replaced Pointer with ID extends IntegerType.

It's a bit of a stop-gap solution, as I can't build a generic Cococa bridge implementing all possible pass-by-value types, but it's got me going again.

Cheers

Duncan

On 15 Nov 2007, at 19:41, Timothy Wall wrote:

On Nov 15, 2007, at 2:15 PM, Duncan McGregor wrote:

Hello, I've another rococoa problem.

The return type from objc_msgSend(id theReceiver, SEL theSelector, ...) is id. This seems to be roughly equivalent to VB Variant or Java Object, now that we have autoboxing, in that it may be a pointer to an object, or a value. However it does seem to hold the actual value of an int by value, rather than reference.

I've mapped this like this

public interface FoundationLibrary extends Library { Pointer objc_msgSend(Pointer receiver, Pointer selector, Object... args); }

Where the return type from sending the message is NSObject all is fine, but sometimes the value answered is, say, the int 1. In this case I get a Pointer pointed at 0x00000001, and can't get the result out of it (without parsing its toString or resorting to reflection).

You might make a dedicated PointerType for selector, then derive from that based on the selector return type (PointerType->Selector-

IntSelector/FloatSelector/etc), with one selector lookup method

per return type. This captures your intent in the signature and types, rather than exposing it as program logic when you convert Object to something else after the method call.

Then you could do as many objc_msgSend() variants as you have return types.

I've purposefully left out arbitrary casts between pointer and primitive values; you can do it if you really have to but usually it's better to make your intent explicit in the interface definitions. If you have a function that can take either an "int" or a "Pointer",

void func(int value); void func(Pointer value);

is preferable to

void func(Object value);

It's a little more tricky with return values, since Java can't overload methods which differ only by return type, so you have to tweak the arguments to be different.