Re: TAP5-1213: Changes to public API
Haha... I could try / catch AbstractMethodError and get rid of Binding2 / PropertyConduit2. Win! Jokes... On 20 May 2014 17:46, "Jochen Kemnade" wrote: > True, but if they occur, the cause is not so easy to find IMO. >
Re: TAP5-1213: Changes to public API
True, but if they occur, the cause is not so easy to find IMO.
Re: TAP5-1213: Changes to public API
I was referring to the exception being rare, not third party implementations. Keep in mind that the exception will only occur when invoking the new method on ComponentResources. At the moment there is no such code in existence. On 20 May 2014 13:51, "Thiago H de Paula Figueiredo" wrote: > On Tue, 20 May 2014 07:20:21 -0300, Lance Java > wrote: > > This would only occur in third party bindings / propertyConduits that >> don't extend core (internal) implementations. >> >> IMHO these exceptions are likely to be rare as hen's teeth ;) >> > > Agreed for ComponentResources, less agreed for Binding and disagreed for > PropertyConduit, which is used inside some projects to implement some > properties for BeanModel-based components. This is *not* uncommon to be > found in non-library code. > > -- > 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 > >
Re: TAP5-1213: Changes to public API
On Tue, 20 May 2014 07:20:21 -0300, Lance Java wrote: This would only occur in third party bindings / propertyConduits that don't extend core (internal) implementations. IMHO these exceptions are likely to be rare as hen's teeth ;) Agreed for ComponentResources, less agreed for Binding and disagreed for PropertyConduit, which is used inside some projects to implement some properties for BeanModel-based components. This is *not* uncommon to be found in non-library code. -- 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
Re: TAP5-1213: Changes to public API
In this instance, I would assume an AbstractMethodError would be thrown when calling the new method: ComponentResources.getBoundGenericType(paramName) This would only occur in third party bindings / propertyConduits that don't extend core (internal) implementations. IMHO these exceptions are likely to be rare as hen's teeth ;) And the exception would only be thrown if the new method is called (e.g. via ComponentResources) which is only the case for new code. So a problem occurs only if new code uses old bindings. Old code that uses old bindings would still work without problems. If I have a voice, I vote for API change in this cases. This is better to have Binding2, Binding2, BindingN (imagine what once would happen if some binding implements Binding 1,2,4 but not 3 ;-) ). Do you think the feature could make it in the new beta? Kind Regards, Michael. -- Mit freundlichen Grüßen / Regards Michael Wyraz evermind GmbH Schorlemmerstraße 1 04155 Leipzig Tel.: +49 (0)341-25 39 66 - 0 Fax:+49 (0)341-25 39 66 - 1 Funk: +49 (0)177-73 00 00 3 E-Mail: michael.wy...@evermind.de HRB: 21586 Amtsgericht Leipzig Geschäftsführer: Christoph Klemm Thomas Grünert Michael Wyraz - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: TAP5-1213: Changes to public API
> wouldn't adding methods to the existing interfaces lead to libraries written for (and compiled against) Tapestry 5.3 would not work with Tapestry 5.4 anymore? In this instance, I would assume an AbstractMethodError would be thrown when calling the new method: ComponentResources.getBoundGenericType(paramName) This would only occur in third party bindings / propertyConduits that don't extend core (internal) implementations. IMHO these exceptions are likely to be rare as hen's teeth ;)
Re: TAP5-1213: Changes to public API
Am 20.05.2014 08:23, schrieb Lance Java: 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? Unfortunately, I haven't had the chance to look at the changes too closely yet, so I'm not sure if this is relevant at all. But wouldn't adding methods to the existing interfaces lead to libraries written for (and compiled against) Tapestry 5.3 would not work with Tapestry 5.4 anymore? Jochen - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: TAP5-1213: Changes to public API
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" 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 >wrote: > > > ok, just committed with Binding2 / PropertyConduit2 keeping backwards > > compatibility in tact. > > > > > > On 19 May 2014 19:02, Lance Java 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 > > >> > > >> > > >
Re: TAP5-1213: Changes to public API
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 wrote: > ok, just committed with Binding2 / PropertyConduit2 keeping backwards > compatibility in tact. > > > On 19 May 2014 19:02, Lance Java 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 > >> > >> >
Re: TAP5-1213: Changes to public API
ok, just committed with Binding2 / PropertyConduit2 keeping backwards compatibility in tact. On 19 May 2014 19:02, Lance Java 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" > wrote: > >> On Mon, 19 May 2014 13:04:55 -0300, Lance Java >> 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 >> >>
Re: TAP5-1213: Changes to public API
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" wrote: > On Mon, 19 May 2014 13:04:55 -0300, Lance Java > 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 > >
Re: TAP5-1213: Changes to public API
On Mon, 19 May 2014 13:04:55 -0300, Lance Java 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
Re: TAP5-1213: Changes to public API
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() On 19 May 2014 15:17, "Thiago H de Paula Figueiredo" wrote: > On Sat, 17 May 2014 14:27:21 -0300, Lance Java > wrote: > > I don't think anyone will be implementing their own ComponentResources or >> PropertyConduit so I think those changes are fin. >> > > Agreed with ComponentResources, not about PropertyConduit, but I still > think that wouldn't be a problem, specially if a new PropertyConduit2 > interface is defined. > > -- > 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 > >
Re: TAP5-1213: Changes to public API
On Sat, 17 May 2014 14:27:21 -0300, Lance Java wrote: I don't think anyone will be implementing their own ComponentResources or PropertyConduit so I think those changes are fin. Agreed with ComponentResources, not about PropertyConduit, but I still think that wouldn't be a problem, specially if a new PropertyConduit2 interface is defined. -- 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
Re: TAP5-1213: Changes to public API
Hi, Java 8 default methods doesn't seem to be a valid solution. They allows to keep an implementation compatible when new methods are added but (as far as I could see) they do not enable binary compatibility (means, the method remains abstract until the implementation is compiled against the new interface, see http://stackoverflow.com/questions/22618493/does-introducing-a-default-method-to-an-interface-really-preserve-back-compatibi for details). So it's more or less compiler magic. But how about a worker that instruments "Binding" implementations where the new method "Binding.getBindingGenericType()" is not implemented and simply add a new Method that redirects to Binding.getBindingType()? Kind regards, Michael. It can be problematic; I don't expect people to implement ComponentResources ... but some other common interfaces, such as FormSupport, are often proxied/delegated in a way that provides pain when new methods are added. JDK 8 default methods may help there, hard to say so far. On Sat, May 17, 2014 at 1:27 PM, Lance Java wrote: I've managed to solve the issue without affecting org.apache.tapestry5.ioc. services.PropertyAdapter. So the introduced methods are: Type Binding.getBindingGenericType() Type PropertyConduit getPropertyGenericType() Type ComponentResources.getBoundGenericType(String parameterName) I don't think anyone will be implementing their own ComponentResources or PropertyConduit so I think those changes are fin. Ashas been mentioned, third parties (including myself) have implemented custom bindings. If it's any consolation, I've implemented AbstractBinding.getBindingGenericType() to simply return getBindingType(). The other solution I can see is to have Binding2 in a similar style to Asset2 etc. On 16 May 2014 00:48, Howard Lewis Ship wrote: I'd need to know a bit more; this will tend to break 3rd party libraries that compile against the old code, which is not so good. Possibly if the new information could be added under an entirely new method of the existing APIs that would be less of a problem. On Wed, May 14, 2014 at 1:33 PM, Lance Java wrote: I'm looking into TAP5-1213 to provide access to the bound property's generic type information (eg List). Basically the generic type information needs to be passed from PropertyConduitSource to ComponentResources This change requires adding a generic type getter to a few public interfaces, namely: - org.apache.tapestry5.Binding - org.apache.tapestry5.ComponentResources - org.apache.tapestry5.PropertyConduit - org.apache.tapestry5.ioc.services.PropertyAdapter I realise that adding methods to public interfaces breaks backwards compatability. What's people's thoughts on this? -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: TAP5-1213: Changes to public API
I've uploaded the patch to jira https://issues.apache.org/jira/browse/TAP5-1213 https://issues.apache.org/jira/secure/attachment/12645469/TAP5-1213.patch Cheers, Lance. On 18 May 2014 16:49, Ulrich Stärk wrote: > If you are unsure you can send the patch here and ask for reviews. > > Uli > > On 2014-05-18 16:39, Lance Java wrote: > > So, is it OK to commit the changes? It will obviously need a breaking > > change note in the release notes. > > On 18 May 2014 00:10, "Howard Lewis Ship" wrote: > > > >> It can be problematic; I don't expect people to implement > >> ComponentResources ... but some other common interfaces, such as > >> FormSupport, are often proxied/delegated in a way that provides pain > when > >> new methods are added. JDK 8 default methods may help there, hard to > say > >> so far. > >> > >> > >> On Sat, May 17, 2014 at 1:27 PM, Lance Java >>> wrote: > >> > >>> I've managed to solve the issue without affecting > >> org.apache.tapestry5.ioc. > >>> services.PropertyAdapter. > >>> > >>> So the introduced methods are: > >>> Type Binding.getBindingGenericType() > >>> Type PropertyConduit getPropertyGenericType() > >>> Type ComponentResources.getBoundGenericType(String parameterName) > >>> > >>> I don't think anyone will be implementing their own ComponentResources > or > >>> PropertyConduit so I think those changes are fin. Ashas been mentioned, > >>> third parties (including myself) have implemented custom bindings. If > >> it's > >>> any consolation, I've implemented > AbstractBinding.getBindingGenericType() > >>> to simply return getBindingType(). > >>> > >>> The other solution I can see is to have Binding2 in a similar style to > >>> Asset2 etc. > >>> > >>> > >>> On 16 May 2014 00:48, Howard Lewis Ship wrote: > >>> > I'd need to know a bit more; this will tend to break 3rd party > >> libraries > that compile against the old code, which is not so good. Possibly if > >> the > new information could be added under an entirely new method of the > >>> existing > APIs that would be less of a problem. > > > On Wed, May 14, 2014 at 1:33 PM, Lance Java < > lance.j...@googlemail.com > > wrote: > > > I'm looking into TAP5-1213 to provide access to the bound property's > > generic type information (eg List). Basically the generic > >>> type > > information needs to be passed from PropertyConduitSource to > > ComponentResources > > > > This change requires adding a generic type getter to a few public > > interfaces, namely: > > - org.apache.tapestry5.Binding > > - org.apache.tapestry5.ComponentResources > > - org.apache.tapestry5.PropertyConduit > > - org.apache.tapestry5.ioc.services.PropertyAdapter > > > > I realise that adding methods to public interfaces breaks backwards > > compatability. What's people's thoughts on this? > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship > > >>> > >> > >> > >> > >> -- > >> Howard M. Lewis Ship > >> > >> Creator of Apache Tapestry > >> > >> The source for Tapestry training, mentoring and support. Contact me to > >> learn how I can get you up and productive in Tapestry fast! > >> > >> (971) 678-5210 > >> http://howardlewisship.com > >> @hlship > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > >
Re: TAP5-1213: Changes to public API
If you are unsure you can send the patch here and ask for reviews. Uli On 2014-05-18 16:39, Lance Java wrote: > So, is it OK to commit the changes? It will obviously need a breaking > change note in the release notes. > On 18 May 2014 00:10, "Howard Lewis Ship" wrote: > >> It can be problematic; I don't expect people to implement >> ComponentResources ... but some other common interfaces, such as >> FormSupport, are often proxied/delegated in a way that provides pain when >> new methods are added. JDK 8 default methods may help there, hard to say >> so far. >> >> >> On Sat, May 17, 2014 at 1:27 PM, Lance Java >> wrote: >> >>> I've managed to solve the issue without affecting >> org.apache.tapestry5.ioc. >>> services.PropertyAdapter. >>> >>> So the introduced methods are: >>> Type Binding.getBindingGenericType() >>> Type PropertyConduit getPropertyGenericType() >>> Type ComponentResources.getBoundGenericType(String parameterName) >>> >>> I don't think anyone will be implementing their own ComponentResources or >>> PropertyConduit so I think those changes are fin. Ashas been mentioned, >>> third parties (including myself) have implemented custom bindings. If >> it's >>> any consolation, I've implemented AbstractBinding.getBindingGenericType() >>> to simply return getBindingType(). >>> >>> The other solution I can see is to have Binding2 in a similar style to >>> Asset2 etc. >>> >>> >>> On 16 May 2014 00:48, Howard Lewis Ship wrote: >>> I'd need to know a bit more; this will tend to break 3rd party >> libraries that compile against the old code, which is not so good. Possibly if >> the new information could be added under an entirely new method of the >>> existing APIs that would be less of a problem. On Wed, May 14, 2014 at 1:33 PM, Lance Java wrote: > I'm looking into TAP5-1213 to provide access to the bound property's > generic type information (eg List). Basically the generic >>> type > information needs to be passed from PropertyConduitSource to > ComponentResources > > This change requires adding a generic type getter to a few public > interfaces, namely: > - org.apache.tapestry5.Binding > - org.apache.tapestry5.ComponentResources > - org.apache.tapestry5.PropertyConduit > - org.apache.tapestry5.ioc.services.PropertyAdapter > > I realise that adding methods to public interfaces breaks backwards > compatability. What's people's thoughts on this? > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> @hlship >> > - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: TAP5-1213: Changes to public API
So, is it OK to commit the changes? It will obviously need a breaking change note in the release notes. On 18 May 2014 00:10, "Howard Lewis Ship" wrote: > It can be problematic; I don't expect people to implement > ComponentResources ... but some other common interfaces, such as > FormSupport, are often proxied/delegated in a way that provides pain when > new methods are added. JDK 8 default methods may help there, hard to say > so far. > > > On Sat, May 17, 2014 at 1:27 PM, Lance Java >wrote: > > > I've managed to solve the issue without affecting > org.apache.tapestry5.ioc. > > services.PropertyAdapter. > > > > So the introduced methods are: > > Type Binding.getBindingGenericType() > > Type PropertyConduit getPropertyGenericType() > > Type ComponentResources.getBoundGenericType(String parameterName) > > > > I don't think anyone will be implementing their own ComponentResources or > > PropertyConduit so I think those changes are fin. Ashas been mentioned, > > third parties (including myself) have implemented custom bindings. If > it's > > any consolation, I've implemented AbstractBinding.getBindingGenericType() > > to simply return getBindingType(). > > > > The other solution I can see is to have Binding2 in a similar style to > > Asset2 etc. > > > > > > On 16 May 2014 00:48, Howard Lewis Ship wrote: > > > > > I'd need to know a bit more; this will tend to break 3rd party > libraries > > > that compile against the old code, which is not so good. Possibly if > the > > > new information could be added under an entirely new method of the > > existing > > > APIs that would be less of a problem. > > > > > > > > > On Wed, May 14, 2014 at 1:33 PM, Lance Java > > >wrote: > > > > > > > I'm looking into TAP5-1213 to provide access to the bound property's > > > > generic type information (eg List). Basically the generic > > type > > > > information needs to be passed from PropertyConduitSource to > > > > ComponentResources > > > > > > > > This change requires adding a generic type getter to a few public > > > > interfaces, namely: > > > > - org.apache.tapestry5.Binding > > > > - org.apache.tapestry5.ComponentResources > > > > - org.apache.tapestry5.PropertyConduit > > > > - org.apache.tapestry5.ioc.services.PropertyAdapter > > > > > > > > I realise that adding methods to public interfaces breaks backwards > > > > compatability. What's people's thoughts on this? > > > > > > > > > > > > > > > > -- > > > Howard M. Lewis Ship > > > > > > Creator of Apache Tapestry > > > > > > The source for Tapestry training, mentoring and support. Contact me to > > > learn how I can get you up and productive in Tapestry fast! > > > > > > (971) 678-5210 > > > http://howardlewisship.com > > > @hlship > > > > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: TAP5-1213: Changes to public API
It can be problematic; I don't expect people to implement ComponentResources ... but some other common interfaces, such as FormSupport, are often proxied/delegated in a way that provides pain when new methods are added. JDK 8 default methods may help there, hard to say so far. On Sat, May 17, 2014 at 1:27 PM, Lance Java wrote: > I've managed to solve the issue without affecting org.apache.tapestry5.ioc. > services.PropertyAdapter. > > So the introduced methods are: > Type Binding.getBindingGenericType() > Type PropertyConduit getPropertyGenericType() > Type ComponentResources.getBoundGenericType(String parameterName) > > I don't think anyone will be implementing their own ComponentResources or > PropertyConduit so I think those changes are fin. Ashas been mentioned, > third parties (including myself) have implemented custom bindings. If it's > any consolation, I've implemented AbstractBinding.getBindingGenericType() > to simply return getBindingType(). > > The other solution I can see is to have Binding2 in a similar style to > Asset2 etc. > > > On 16 May 2014 00:48, Howard Lewis Ship wrote: > > > I'd need to know a bit more; this will tend to break 3rd party libraries > > that compile against the old code, which is not so good. Possibly if the > > new information could be added under an entirely new method of the > existing > > APIs that would be less of a problem. > > > > > > On Wed, May 14, 2014 at 1:33 PM, Lance Java > >wrote: > > > > > I'm looking into TAP5-1213 to provide access to the bound property's > > > generic type information (eg List). Basically the generic > type > > > information needs to be passed from PropertyConduitSource to > > > ComponentResources > > > > > > This change requires adding a generic type getter to a few public > > > interfaces, namely: > > > - org.apache.tapestry5.Binding > > > - org.apache.tapestry5.ComponentResources > > > - org.apache.tapestry5.PropertyConduit > > > - org.apache.tapestry5.ioc.services.PropertyAdapter > > > > > > I realise that adding methods to public interfaces breaks backwards > > > compatability. What's people's thoughts on this? > > > > > > > > > > > -- > > Howard M. Lewis Ship > > > > Creator of Apache Tapestry > > > > The source for Tapestry training, mentoring and support. Contact me to > > learn how I can get you up and productive in Tapestry fast! > > > > (971) 678-5210 > > http://howardlewisship.com > > @hlship > > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship
Re: TAP5-1213: Changes to public API
I've managed to solve the issue without affecting org.apache.tapestry5.ioc. services.PropertyAdapter. So the introduced methods are: Type Binding.getBindingGenericType() Type PropertyConduit getPropertyGenericType() Type ComponentResources.getBoundGenericType(String parameterName) I don't think anyone will be implementing their own ComponentResources or PropertyConduit so I think those changes are fin. Ashas been mentioned, third parties (including myself) have implemented custom bindings. If it's any consolation, I've implemented AbstractBinding.getBindingGenericType() to simply return getBindingType(). The other solution I can see is to have Binding2 in a similar style to Asset2 etc. On 16 May 2014 00:48, Howard Lewis Ship wrote: > I'd need to know a bit more; this will tend to break 3rd party libraries > that compile against the old code, which is not so good. Possibly if the > new information could be added under an entirely new method of the existing > APIs that would be less of a problem. > > > On Wed, May 14, 2014 at 1:33 PM, Lance Java >wrote: > > > I'm looking into TAP5-1213 to provide access to the bound property's > > generic type information (eg List). Basically the generic type > > information needs to be passed from PropertyConduitSource to > > ComponentResources > > > > This change requires adding a generic type getter to a few public > > interfaces, namely: > > - org.apache.tapestry5.Binding > > - org.apache.tapestry5.ComponentResources > > - org.apache.tapestry5.PropertyConduit > > - org.apache.tapestry5.ioc.services.PropertyAdapter > > > > I realise that adding methods to public interfaces breaks backwards > > compatability. What's people's thoughts on this? > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > @hlship >
Re: TAP5-1213: Changes to public API
I'd need to know a bit more; this will tend to break 3rd party libraries that compile against the old code, which is not so good. Possibly if the new information could be added under an entirely new method of the existing APIs that would be less of a problem. On Wed, May 14, 2014 at 1:33 PM, Lance Java wrote: > I'm looking into TAP5-1213 to provide access to the bound property's > generic type information (eg List). Basically the generic type > information needs to be passed from PropertyConduitSource to > ComponentResources > > This change requires adding a generic type getter to a few public > interfaces, namely: > - org.apache.tapestry5.Binding > - org.apache.tapestry5.ComponentResources > - org.apache.tapestry5.PropertyConduit > - org.apache.tapestry5.ioc.services.PropertyAdapter > > I realise that adding methods to public interfaces breaks backwards > compatability. What's people's thoughts on this? > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com @hlship
Re: TAP5-1213: Changes to public API
Hi Lance, as far as I can see the public API was extended several times in the past. A lot methods are marked as @since 5.2. The only potential problem I see is in "Binding" since people might have implemented their own. It's quite unlikely that someone has it's own ComponentResources and such. An alternative (especially for Binding) would be to create an Interface "GenericsAwareBinding" that extends Binding with the new method. Implementations could use the new Method if the binding is generic aware and otherwise fall back to the old "getBindingType". Maybe this can even be achieved using instrumentation magic (dynamically add the method if it is missing and fall back to the non-generic)? Theoretically it should be possible to have a worker which detect if e.g. "Binding" is an interface but the new Method is missing. I'm looking into TAP5-1213 to provide access to the bound property's generic type information (eg List). Basically the generic type information needs to be passed from PropertyConduitSource to ComponentResources This change requires adding a generic type getter to a few public interfaces, namely: - org.apache.tapestry5.Binding - org.apache.tapestry5.ComponentResources - org.apache.tapestry5.PropertyConduit - org.apache.tapestry5.ioc.services.PropertyAdapter I realise that adding methods to public interfaces breaks backwards compatability. What's people's thoughts on this? -- Mit freundlichen Grüßen / Kind regards Michael Wyraz evermind GmbH Schorlemmerstraße 1 04155 Leipzig Tel.: +49 (0)341-25 39 66 - 0 Fax:+49 (0)341-25 39 66 - 1 Funk: +49 (0)177-73 00 00 3 E-Mail: michael.wy...@evermind.de HRB: 21586 Amtsgericht Leipzig Geschäftsführer: Christoph Klemm - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
TAP5-1213: Changes to public API
I'm looking into TAP5-1213 to provide access to the bound property's generic type information (eg List). Basically the generic type information needs to be passed from PropertyConduitSource to ComponentResources This change requires adding a generic type getter to a few public interfaces, namely: - org.apache.tapestry5.Binding - org.apache.tapestry5.ComponentResources - org.apache.tapestry5.PropertyConduit - org.apache.tapestry5.ioc.services.PropertyAdapter I realise that adding methods to public interfaces breaks backwards compatability. What's people's thoughts on this?