Re: [xmlvm-dev] NSSelector

[Paul P. <bay...@gm...>]

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