I am with Joe, this is too big and breaking of a change for a small
semantic win.
Another approach might be to define an execute method in a plugin ( pick
one ) and have it self reflect, and call it's own exposed methods.
@Override
public boolean execute(String action, JSONArray args, CallbackContext
callbackContext) throws JSONException {
// pseudocode ...
if(this[action]) {
return this[action](args, callbackContext);
}
return false; // Returning false results in a "MethodNotFound"
error.
}
Then every callable method would be :
boolean methodName(JSONArray args, CallbackContext callbackContext) throws
JSONException
Potentially this could become the base class implementation of 'execute'
and presumably nothing would break ...
@purplecabbage
risingj.com
On Thu, May 29, 2014 at 12:01 PM, Joe Bowser <bows...@gmail.com> wrote:
> On Thu, May 29, 2014 at 11:46 AM, Erik Jan de Wit <ede...@redhat.com>
> wrote:
> >
> >> What is the benefit of using this logic? I personally don't see any
> >> benefit, since this makes our code more complex.
> >
> > It would benefit the users as they don’t have to implement this
> boilerplate code of dispatching based on the string. And this logic will be
> then on the android side where it’s implemented once instead of each time
> one is building a plugin.
>
> Except that now every method exposed has to have a particular
> signature. I personally would rather see us use a Map as what Andrew
> suggested, and I really don't want this to happen. This is going to
> cause a lot more problems than it's going to solve since plugins that
> already throw exceptions may end up having it caught by the try/catch
> which will surround this whole thing. This is a BIG change in the
> API, and I don't think your reason justifies breaking every plugin
> that currently exists.
>
