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 <lance.j...@googlemail.com>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 <hls...@gmail.com> 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<SomeBean>). 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
