Menu
▾
▴
xmlvm-developers
|
From: Panayotis K. <pan...@pa...> - 2011-03-23 16:17:43
|
After some previous discussions, I have decided to have a better view at the NSObject.performSelector method. Here is a proposal, to fix it before I start making drastic changes: http://xmlvm-reviews.appspot.com/111006 This patch is far from being ready for submission, it is more to have a look at the API first. The two important files are: http://xmlvm-reviews.appspot.com/111006/diff/1/src/xmlvm2objc/compat-lib/java/org/xmlvm/iphone/NSObject.java and http://xmlvm-reviews.appspot.com/111006/patch/1/3 What do you think? PS: I was a bit influenced by this object: http://www.spice-of-life.net/wodock/api/com/webobjects/foundation/NSSelector.html |
|
From: Arno P. <ar...@pu...> - 2011-03-23 21:29:28
|
I am absolutely OK with the patch. I personally have favored making use of strongly typed API when creating the Java Cocoa API and that is what you do for NSSelector. HOWEVER: your patch does not make the necessary changes to the C backend. If you commit the patch as-is, it will break the C backend. Its OK to continue to do work on the Objective-C backend while we are still in transition, but I would expect that whatever change is done to the Objective-C backend is also done with the C backend. Arno On 3/23/2011 9:17 AM, Panayotis Katsaloulis wrote: > After some previous discussions, I have decided to have a better view at the > NSObject.performSelector method. > > Here is a proposal, to fix it before I start making drastic changes: > > http://xmlvm-reviews.appspot.com/111006 > > This patch is far from being ready for submission, it is more to have a look at the API first. > The two important files are: > http://xmlvm-reviews.appspot.com/111006/diff/1/src/xmlvm2objc/compat-lib/java/org/xmlvm/iphone/NSObject.java > and > http://xmlvm-reviews.appspot.com/111006/patch/1/3 > > What do you think? > > > PS: I was a bit influenced by this object: > http://www.spice-of-life.net/wodock/api/com/webobjects/foundation/NSSelector.html > ------------------------------------------------------------------------------ > 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 |
|
From: Panayotis K. <pan...@pa...> - 2011-03-23 21:40:26
|
On Mar 23, 2011, at 11:29 PM, Arno Puder wrote: > > I am absolutely OK with the patch. I personally have favored making use > of strongly typed API when creating the Java Cocoa API and that is what > you do for NSSelector. > > HOWEVER: your patch does not make the necessary changes to the C > backend. If you commit the patch as-is, it will break the C backend. Its > OK to continue to do work on the Objective-C backend while we are still > in transition, but I would expect that whatever change is done to the > Objective-C backend is also done with the C backend. > > Arno Right now the patch is half-ready. It is only a presentation of the API I propose (alongside the necessary changes for Android to be compatible). There are not even bindings for the ObjC backend, so it still needs a lot of work. I just wanted to be sure that you agree with this change before spend more time with it. |
|
From: Arno P. <ar...@pu...> - 2011-03-23 21:42:46
|
On 3/23/2011 2:40 PM, Panayotis Katsaloulis wrote: > Right now the patch is half-ready. > It is only a presentation of the API I propose (alongside the necessary changes for Android to be compatible). > There are not even bindings for the ObjC backend, so it still needs a lot of work. > > I just wanted to be sure that you agree with this change before spend more time with it. your patch is definitely going in the right direction. Time to get your hands dirty with the C backend! :) Arno |
|
From: Paul P. <bay...@gm...> - 2011-03-23 23:59:15
|
Yep, I try to avoid reflection at all costs. I had made a similar class so
that there's only one place where reflection occurs. So instead of
performSelector..., I call performRunnable...
package blah.blah.blah;
import org.xmlvm.iphone.NSObject;
import blah.blah.Logger;
public class IPhoneUtil {
private static final Logger log = new Logger(IPhoneUtil.class);
private static IPhoneUtil utilInstance = new IPhoneUtil();
private IPhoneUtil() {
}
public static void performRunnableOnMainThread(Runnable runnable,
booleanwaitUntilDone) {
NSObject.performSelectorOnMainThread(utilInstance, "executeRunnable",
runnable, waitUntilDone);
}
/**
* Execute a runnable on the main thread. This is only called via reflection
* using performSelectorOnMainThread
* @param arg the Runnable object
*/
public void executeRunnable(Object arg) {
if (arg instanceof Runnable) {
Runnable r = (Runnable)arg;
r.run();
} else {
log.info("Could not execute Runnable. Unexpected parameter type: "
+ (arg == null ? null : arg.getClass().getName()));
}
}
}
On Wed, Mar 23, 2011 at 4:42 PM, Arno Puder <ar...@pu...> wrote:
>
>
> On 3/23/2011 2:40 PM, Panayotis Katsaloulis wrote:
> > Right now the patch is half-ready.
> > It is only a presentation of the API I propose (alongside the necessary
> changes for Android to be compatible).
> > There are not even bindings for the ObjC backend, so it still needs a lot
> of work.
> >
> > I just wanted to be sure that you agree with this change before spend
> more time with it.
>
> your patch is definitely going in the right direction. Time to get your
> hands dirty with the C backend! :)
>
> Arno
>
>
|
|
From: Arno P. <ar...@pu...> - 2011-03-24 07:28:25
|
that is certainly also an interesting alternative: instead of
introducing a new interface NSSelector, simply use Runnable.
Panayotis: what do you think?
Arno
On 3/23/11 4:59 PM, Paul Poley wrote:
> Yep, I try to avoid reflection at all costs. I had made a similar class
> so that there's only one place where reflection occurs. So instead of
> performSelector..., I call performRunnable...
>
> package blah.blah.blah;
>
>
> import org.xmlvm.iphone.NSObject;
>
> import blah.blah.Logger;
>
>
> public class IPhoneUtil {
>
> private static final Logger log = new Logger(IPhoneUtil.class);
>
>
> private static IPhoneUtil utilInstance = new IPhoneUtil();
>
>
> private IPhoneUtil() {
>
>
> }
>
>
> public static void performRunnableOnMainThread(Runnable runnable,
> boolean waitUntilDone) {
>
> NSObject.performSelectorOnMainThread(utilInstance, "executeRunnable",
> runnable, waitUntilDone);
>
> }
>
>
> /**
>
> * Execute a runnable on the main thread. This is only called via reflection
>
> * using performSelectorOnMainThread
>
> * @param arg the Runnable object
>
> */
>
> public void executeRunnable(Object arg) {
>
> if (arg instanceof Runnable) {
>
> Runnable r = (Runnable)arg;
>
> r.run();
>
> } else {
>
> log.info("Could not execute Runnable. Unexpected parameter type: "
>
> + (arg == null ? null : arg.getClass().getName()));
>
> }
>
> }
>
> }
>
>
>
> On Wed, Mar 23, 2011 at 4:42 PM, Arno Puder <ar...@pu...
> <mailto:ar...@pu...>> wrote:
>
>
>
> On 3/23/2011 2:40 PM, Panayotis Katsaloulis wrote:
> > Right now the patch is half-ready.
> > It is only a presentation of the API I propose (alongside the
> necessary changes for Android to be compatible).
> > There are not even bindings for the ObjC backend, so it still
> needs a lot of work.
> >
> > I just wanted to be sure that you agree with this change before
> spend more time with it.
>
> your patch is definitely going in the right direction. Time to get your
> hands dirty with the C backend! :)
>
> Arno
>
|
|
From: Panayotis K. <pan...@pa...> - 2011-03-24 10:44:54
|
On Mar 24, 2011, at 9:27 AM, Arno Puder wrote: > > that is certainly also an interesting alternative: instead of > introducing a new interface NSSelector, simply use Runnable. > > Panayotis: what do you think? > > Arno This was my first intention. Unfortunately it is not possible, since we need an argument for this method, but the "run" method is without arguments. |
|
From: Paul P. <bay...@gm...> - 2011-03-24 14:12:54
|
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. Thanks, Paul On Thu, Mar 24, 2011 at 5:44 AM, Panayotis Katsaloulis < pan...@pa...> wrote: > > On Mar 24, 2011, at 9:27 AM, Arno Puder wrote: > > > > > that is certainly also an interesting alternative: instead of > > introducing a new interface NSSelector, simply use Runnable. > > > > Panayotis: what do you think? > > > > Arno > > > This was my first intention. > Unfortunately it is not possible, since we need an argument for this > method, but the "run" method is without arguments. > > |
|
From: Panayotis K. <pan...@pa...> - 2011-03-24 14:21:54
|
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. |
|
From: Paul P. <bay...@gm...> - 2011-03-24 14:53:59
|
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. > > |
|
From: Panayotis K. <pan...@pa...> - 2011-03-24 16:50:44
|
So, to conclude, what the others also say about the API? What should I do? |
|
From: Arno P. <ar...@pu...> - 2011-03-25 01:19:58
|
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 |
|
From: Panayotis K. <pan...@pa...> - 2011-03-26 10:46:59
|
On Mar 25, 2011, at 3:19 AM, Arno Puder wrote: > > 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) I am actually more in favor of this solution, because it is similar (or practically the same) with NSTimerDelegate > 2. NSObject.performSelectorOnMainThread(Runnable) > 3. NSObject.performRunnableOnMainThread(Runnable) I am afraid that this is not standard and nowhere documented, and I am not really in favor for introducing non-existive API. More importantly though, it is required the others to express their opinion. |
|
From: Arno P. <ar...@pu...> - 2011-03-26 16:55:54
|
I agree with you that (1) the name of a class/method should reflect its semantics and (2) we should stick to the official API as much as possible. In light of this, I also opt for the first option I mentioned NSObject.performSelectorOnMainThread(NSSelector). Arno On 3/26/11 3:46 AM, Panayotis Katsaloulis wrote: > > On Mar 25, 2011, at 3:19 AM, Arno Puder wrote: > >> >> 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) > > I am actually more in favor of this solution, because it is similar (or practically the same) with NSTimerDelegate > >> 2. NSObject.performSelectorOnMainThread(Runnable) >> 3. NSObject.performRunnableOnMainThread(Runnable) > > I am afraid that this is not standard and nowhere documented, and I am not really in favor for introducing non-existive API. > > > More importantly though, it is required the others to express their opinion. > ------------------------------------------------------------------------------ > 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 |
|
From: Paul P. <bay...@gm...> - 2011-03-26 19:34:11
|
That's fine with me too. Paul On Sat, Mar 26, 2011 at 11:55 AM, Arno Puder <ar...@pu...> wrote: > > I agree with you that (1) the name of a class/method should reflect its > semantics and (2) we should stick to the official API as much as > possible. In light of this, I also opt for the first option I mentioned > NSObject.performSelectorOnMainThread(NSSelector). > > Arno > > > On 3/26/11 3:46 AM, Panayotis Katsaloulis wrote: > > > > On Mar 25, 2011, at 3:19 AM, Arno Puder wrote: > > > >> > >> 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) > > > > I am actually more in favor of this solution, because it is similar (or > practically the same) with NSTimerDelegate > > > >> 2. NSObject.performSelectorOnMainThread(Runnable) > >> 3. NSObject.performRunnableOnMainThread(Runnable) > > > > I am afraid that this is not standard and nowhere documented, and I am > not really in favor for introducing non-existive API. > > > > > > More importantly though, it is required the others to express their > opinion. > |
|
From: Arno P. <ar...@pu...> - 2011-03-28 16:35:16
|
I wanted to make one more comment concerning the overall issue: you may have noticed that there is a branch called branches/wp7. Markus and Oren are working in that branch to add another backend to XMLVM for WP7. The current version of XMLVM's Android Compat Lib is tied to iOS and the discussion we've had here with NSSelector is a good example. NSObject.performSelectorOnMainThread() is currently used in various places in the Android Compat Lib to run tasks on the UI thread, however, that class and method are iOS specific. One job that Oren and Markus will soon be working on is to refactor the Android Compat Lib and add a well-defined "Common Device API" that will make it easier to add new backends to XMLVM. So, instead of using NSObject/NSSelector all over the Android Compat Lib, the plan is to create an abstraction. Same is true for other iOS API that is used liberally throughout the Android Compat Lib, e.g., NSXMLParser, NSData, etc. Now, I just mention this to give a glimpse on things to come with XMLVM. It doesn't affect the current discussion and decisions regarding NSSelector. Panayotis patch is already introducing NSSelector within the Android Compat Lib. Once we advance with WP7, this will change again to the aforementioned Common Device API. I'm sure the WP7 guys will introduce their refactoring plans on this list for general discussion. Arno On 3/26/11 12:34 PM, Paul Poley wrote: > That's fine with me too. > > Paul > > On Sat, Mar 26, 2011 at 11:55 AM, Arno Puder <ar...@pu... > <mailto:ar...@pu...>> wrote: > > > I agree with you that (1) the name of a class/method should reflect its > semantics and (2) we should stick to the official API as much as > possible. In light of this, I also opt for the first option I mentioned > NSObject.performSelectorOnMainThread(NSSelector). > > Arno > > > On 3/26/11 3:46 AM, Panayotis Katsaloulis wrote: > > > > On Mar 25, 2011, at 3:19 AM, Arno Puder wrote: > > > >> > >> 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) > > > > I am actually more in favor of this solution, because it is > similar (or practically the same) with NSTimerDelegate > > > >> 2. NSObject.performSelectorOnMainThread(Runnable) > >> 3. NSObject.performRunnableOnMainThread(Runnable) > > > > I am afraid that this is not standard and nowhere documented, and > I am not really in favor for introducing non-existive API. > > > > > > More importantly though, it is required the others to express > their opinion. > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X