cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Android - Removing the .api namespace
Date Tue, 09 Jul 2013 23:22:28 GMT
This creates more work one week prior to release. If we didn't have a
deadline for this release, I'd be OK with it, but this means that the
trivial change would have to happen to all our plugins.  Given the time
constraint, I think we shouldn't do it.

There's also the fact that our plugin developers hate all change, no matter
how reasonable it may seem.

That's why I think this should go in 3.1 or 3.2.
On Jul 9, 2013 4:12 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:

>  :) okay, now let's see if I can convince you Joe.
>
> What I've done so far was put classes in o.a.c.api that extend the actual
> implementations in o.a.c. This is a bit more annoying than I'd like,
> because for it work properly, most types must continue to refer to the
> o.a.c.api classes, or else you'll get a type errors when dealing with
> non-updated code that expects a o.a.c.api class.
>
> Using a separate namespace (.api) to indicate which methods are a part of
> our public API has the huge draw-back of not allowing us to make use of
> package-private visibility with the classes in the non-.api namespace. This
> is my main motivation for the change. I think Java devs often assume any
> symbol that is public is a part of our API, and I think that's pretty
> reasonable. Going forward, we should make an effort to convert public
> symbols to package-private symbols. This will break any plugin that is
> relying on the symbol, but will *not* break any plugins that are not using
> the symbol. OTOH, a namespace change, as we're doing here, will break all
> plugins.
>
> So... I'd like to do the complete namespace change now so that when
> we privatize symbols that we don't want to be a part of our public API, it
> will not break the large majority of plugins.
>
> If you're not convinced, please say why :)
>
>
>
>
>
>
>
>
> On Tue, Jul 9, 2013 at 5:33 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > Actually, on second thought, no, let's keep the compatibility classes
> > in for now.  We may want to keep using this namespace post-3.0.  I
> > think I misunderstood what was being asked.
> >
> > On Tue, Jul 9, 2013 at 2:28 PM, Joe Bowser <bowserj@gmail.com> wrote:
> > > On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > >> Want to bring this up again.
> > >>
> > >> There was a bit of discussion on the bug:
> > >> https://issues.apache.org/jira/browse/CB-4038
> > >>
> > >> I've already gone ahead with creating backward-compatiblity classes in
> > the
> > >> .api namespace, but I think it would be better to just delete them.
> > >>
> > >> Main points in favour:
> > >> 1. For 3.0, people will need to do some work to their plugins anyways
> > (add
> > >> plugin.xml + refactor their JS into modules comes to mind)
> > >> 2. The change to plugins is trivial. Just replace all occurrences of
> > >> "import org.apache.cordova.api" with "import org.apache.cordova".
> > >>
> > >
> > > I'm OK with it for now, only because we don't have the time to
> > > formalize the Android Plugin API.  I would have liked to keep the api
> > > separation but perhaps we can revisit this 3.1 or 3.2.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message