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
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
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:
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
On Tue, 20 May 2014 07:20:21 -0300, Lance Java lance.j...@googlemail.com
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,
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
True, but if they occur, the cause is not so easy to find IMO.
Haha... I could try / catch AbstractMethodError and get rid of Binding2 /
PropertyConduit2. Win!
Jokes...
On 20 May 2014 17:46, Jochen Kemnade kemn...@gmail.com wrote:
True, but if they occur, the cause is not so easy to find IMO.
On Sat, 17 May 2014 14:27:21 -0300, Lance Java lance.j...@googlemail.com
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
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
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
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
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
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
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 hls...@gmail.com wrote:
It can be problematic; I don't expect people to implement
ComponentResources ... but some other common interfaces, such as
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 hls...@gmail.com wrote:
It can be
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 u...@spielviel.de wrote:
If you are unsure you can send the patch here and ask for
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
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
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,
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.
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,
I'm looking into TAP5-1213 to provide access to the bound property's
generic type information (eg ListSomeBean). 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,
23 matches
Mail list logo
