This has implications for API versioning,
I think developers of third party code can assume that the API of public
methods, including constructors, will remain stable across minor revisions
of a library. If a constructor is public then we, the Proton developers,
have an obligation to respect this assumption (or at least to add "for
internal use only" to its Javadoc).
On reflection, I'm coming round to the idea that keeping these constructors
public will place unreasonable restrictions on our ability to evolve the
implementation whilst keeping the API stable.
Phil
On 25 January 2013 14:51, Rob Godfrey <rob.j.godf...@gmail.com> wrote:
> What's your need for the direct constructor?
>
>
> -- Rob
>
> On 25 January 2013 15:49, Hiram Chirino <hi...@hiramchirino.com> wrote:
> > Let me clarify, I have no problem with adding Factories and using them
> > everywhere possible. Just don't take my access away from direct
> > constructors.
> >
> >
> > On Fri, Jan 25, 2013 at 9:39 AM, Rob Godfrey <rob.j.godf...@gmail.com
> >wrote:
> >
> >> In general dependency on implementation is bad, dependency on interface
> is
> >> better. One of the problems we've had with Qpid historically is it
> become
> >> hard to test as we have dependencies on implementation everywhere.
> >>
> >> From an end user perspective the difference is only replacing
> >>
> >> X x = new X();
> >>
> >> with
> >>
> >> X x = XFactory.newInstance();
> >>
> >> But it makes it a lot easier to properly describe the functionality
> being
> >> returned. For implementation reasons, the concrete class may have public
> >> methods that are not intended to be exposed to the application
> programmer
> >> but only to other cooperating classes. To avoid confusion, and to make
> it
> >> clear to us the delta between the "shared" API and the API extensions
> that
> >> we are supporting for the pure Java implementation the interfaces seem
> like
> >> the right way to go for me.
> >>
> >> The idea is that those who need the extension features will still have a
> >> very clear way to get the implementation that provides these, without
> ever
> >> having to cast.
> >>
> >> -- Rob
> >>
> >>
> >>
> >>
> >>
> >> On 24 January 2013 20:03, Rafael Schloming <r...@alum.mit.edu> wrote:
> >>
> >> > On Thu, Jan 24, 2013 at 5:06 AM, Rob Godfrey <rob.j.godf...@gmail.com
> >> > >wrote:
> >> >
> >> > > On 23 January 2013 17:36, Phil Harvey <p...@philharveyonline.com>
> >> wrote:
> >> > > >
> >> > > > As part of the Proton JNI work, I would like to remove all calls
> to
> >> > > > proton-j implementation constructors from "client code". I intend
> >> that
> >> > > > factories will be used instead [1], thereby abstracting away
> whether
> >> > the
> >> > > > implementation is pure Java or proton-c-via-JNI.
> >> > > >
> >> > > > I'd like to check that folks are happy with me making this change,
> >> and
> >> > to
> >> > > > mention a couple of problems I've had.
> >> > > >
> >> > > > In this context, "client code" is anything outside the current
> >> > > > sub-component, where our sub-components are Engine, Codec, Driver,
> >> > > Message
> >> > > > and Messenger, plus each of the contrib modules, and of course
> third
> >> > > party
> >> > > > code.
> >> > > >
> >> > > > To enforce this abstraction, I am planning to make the
> constructors
> >> of
> >> > > the
> >> > > > affected classes package-private where possible. I believe that,
> >> > > although
> >> > > > third party projects might already be calling these constructors,
> it
> >> is
> >> > > > acceptable for us to change its public API in this manner while
> >> Proton
> >> > is
> >> > > > such a young project.
> >> > > >
> >> > >
> >> > > +1 to all of the above
> >> > >
> >> > > >
> >> > > > Please shout if you disagree with any of the above.
> >> > > >
> >> > > > Now, onto my problem. I started off with the
> >> > > org.apache.qpid.proton.engine.
> >> > > > impl package, and found that
> o.a.q.p.hawtdispatch.impl.AmqpTransport
> >> > > calls
> >> > > > various methods on ConnectionImpl and TransportImpl, so simply
> using
> >> a
> >> > > > Connection and Transport will not work. I don't know what to do
> >> about
> >> > > > this, and would welcome people's opinions.
> >> > > >
> >> > >
> >> > > So, the simplest change would be to change the factories to use
> >> > > covariant return types
> >> > >
> >> > > e.g. EngingFactoryImpl becomes:
> >> > >
> >> > > @Override
> >> > > public ConnectionImpl createConnection()
> >> > > {
> >> > > return new ConnectionImpl();
> >> > > }
> >> > >
> >> > > @Override
> >> > > public TransportImpl createTransport()
> >> > > {
> >> > > return new TransportImpl();
> >> > > }
> >> > >
> >> > >
> >> > > ... etc
> >> > >
> >> > > Code that requires the extended functionality offered by the pure
> Java
> >> > > implementation can thus instantiate the desired Factory directly.
> >> > >
> >> >
> >> > What's the point of going through the factory in this scenario rather
> >> than
> >> > directly instantiating the classes as Hiram suggests? Is there some
> class
> >> > of thing the factory would/could do that the constructor
> can't/shouldn't?
> >> >
> >> > A second refinement might be to actually separate out the interface
> >> > > and implementation within the pure Java implementation so that we
> have
> >> > > a well defined "extended" Java API. This interface could then be
> the
> >> > > return type of the factory.
> >> > >
> >> >
> >> > Maybe I'm misunderstanding, but what's the point of using an interface
> >> here
> >> > if you're still locked into the pure Java impl? Are you expecting to
> swap
> >> > out that impl under some circumstances?
> >> >
> >> > --Rafael
> >> >
> >>
> >
> >
> >
> > --
> >
> > **
> >
> > *Hiram Chirino*
> >
> > *Engineering | Red Hat, Inc.*
> >
> > *hchir...@redhat.com <hchir...@redhat.com> | fusesource.com | redhat.com
> *
> >
> > *skype: hiramchirino | twitter: @hiramchirino<
> http://twitter.com/hiramchirino>
> > *
> >
> > *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*
>
