This is also my impression about Hirams work.
So I'm not sure why there is resistance to the changes being proposed
as it's only going to benefit in the long run should the impl changes.
(I do understand that there will be some initial work in changing the
code to use the factories and interfaces).
I also thought part of Phil's (and Rob's) work was to come up with a
set of interfaces for the API.
If I'm not mistaken this work is already sitting in a branch ? (I
stand to be corrected though).
Rajith
On Fri, Jan 25, 2013 at 3:44 PM, Rafael Schloming <r...@alum.mit.edu> wrote:
> FWIW, I don't think Hiram's usage fundamentally needs to depend on the pure
> Java impl. I may be out of date on this one, but I believe his access of
> the implementation was done for expediency. I know at least in a number of
> cases we discussed how the C implementation could accommodate his
> requirements, and we plan do to so at some point. Perhaps our efforts here
> would be better spent in building out the interface so that he doesn't need
> direct access to the implementation.
>
> --Rafael
>
> On Fri, Jan 25, 2013 at 10:31 AM, Phil Harvey
> <p...@philharveyonline.com>wrote:
>
>> 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/>*
>> >
>>
