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
