Re: [xmlvm-dev] NSSelector

[Arno P. <ar...@pu...>]

I guess the question boils down to the way to define the callback in 
Java. Introduce a new interface (NSSelector) or use existing Java 
interface (Runnable)? The method in question is 
NSObject.performSelectorOnMainThread(). Considering the name of the 
method, it might be awkward to pass a runnable. Perhaps renaming the 
method to NSObject.performRunnableOnMainThread() although it doesn't 
exists on the Objective-C side.

So, the options are:

1. NSObject.performSelectorOnMainThread(NSSelector)
2. NSObject.performSelectorOnMainThread(Runnable)
3. NSObject.performRunnableOnMainThread(Runnable)

Opinions anyone?

Arno


On 3/24/11 7:53 AM, Paul Poley wrote:
> I would not say wrapping performSelector... with a Runnable does not
> stick to the Obj-C API.  That's not to say I'm objecting to your
> solution either.
>
> Just so I can understand what you mean, could you expand upon what
> doesn't stick to it?  After all, just because it was originally written
> in Java doesn't mean it's not Obj-C after translation.  Considering the
> end result is running in Obj-C, it seems it is not possible to write
> code that works unless it is sticking to the Obj-C API.
>
> Thanks,
> Paul
>
> On Thu, Mar 24, 2011 at 9:21 AM, Panayotis Katsaloulis
> <pan...@pa... <mailto:pan...@pa...>> wrote:
>
>
>     On Mar 24, 2011, at 4:12 PM, Paul Poley wrote:
>
>      > Fortunately with XMLVM we can make use of "final" variables,
>     which are accessible inside run(), so you don't need an argument.
>       Most of the time you'll probably be writing anonymous inner
>     classes, which can use those variables.  And a more standard class
>     that implements Runnable can store variables as members.
>      >
>      > The nature of Objective-C makes it more difficult to use
>     performSelectorOnMainThread if we didn't have a place to stick an
>     argument, but Java & therefore XMLVM makes it simple.
>
>
>     This approach is indeed true, my objection though is we don't stick
>     to the ObjC API then.
>     This specific method is an ObjC selector, not a Java interface, and
>     thus I believe we should stick to the official API as much as we can
>     (even if we create something in-between that doesn't really exist).
>
>     The situation is exactly similar with the NSTimerDelegate - at that
>     point we could use a Runnable instead of the "NSTimerDelegate" to do
>     the same job.
>     Still I believe the path which was followed up to now (a
>     non-existing interface) is the best.
>
>
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
>
>
>
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers