I agree but thought I was in the minority. The extra interfaces have increased the complexity and require third parties to know about the nuances of the implementation. Adding methods to the public API may cause compilation errors (in rare cases) but at least it's clear.
Anyone else have an opinion? On 20 May 2014 00:13, "Kalle Korhonen" <kalle.o.korho...@gmail.com> wrote: > JMHO, maintaining backwards compatibility in this case isn't worth the > added complexity. Making support libraries compatible requires just > compiling them against the new version and there are many other, more > drastic changes in 5.4 that require at least a re-compilation and in many > cases, changes in the library code. Just my point of view as an author of > multiple T5.4 support libraries. > > Kalle > > > On Mon, May 19, 2014 at 1:52 PM, Lance Java <lance.j...@googlemail.com > >wrote: > > > ok, just committed with Binding2 / PropertyConduit2 keeping backwards > > compatibility in tact. > > > > > > On 19 May 2014 19:02, Lance Java <lance.j...@googlemail.com> wrote: > > > > > I can implement like that if others agree. I just hate instanceof > > littered > > > around the place. > > > > > > It also brings up the possibility of third parties wrapping a Binding2 > > > with a Binding and losing functionality. I'd prefer a compilation error > > > myself. > > > On 19 May 2014 17:46, "Thiago H de Paula Figueiredo" < > > thiag...@gmail.com> > > > wrote: > > > > > >> On Mon, 19 May 2014 13:04:55 -0300, Lance Java < > > lance.j...@googlemail.com> > > >> wrote: > > >> > > >> I guess my question is, is it worth adding / maintaining Binding2 and > > >>> PropertyConduit2 and all the type checking / adapting. > > >>> > > >>> Or are we happy to add the methods to the public API given its a no > > >>> brainer to implement getGenericType() to return getType() > > >>> > > >> > > >> Considering we've dealt with this kind of scenario using the first > > option > > >> (Binding2 and PropertyConduit2), I'd go with it. I guess just a > handful > > of > > >> places would need to be adapted. > > >> > > >> -- > > >> Thiago H. de Paula Figueiredo > > >> Tapestry, Java and Hibernate consultant and developer > > >> http://machina.com.br > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > > >> For additional commands, e-mail: dev-h...@tapestry.apache.org > > >> > > >> > > >
