Hi Thiago,
I didn't want to argue with you, just wanted to explain my opinion (and
understand yours). I can accept the decision to stay with private
methods althought I do not agree with you reasons ^^
I'll continue to discuss smaller changes (in behaviour) here.
Kind regards,
Michael.
On Tue, 13 May 2014 05:25:22 -0300, Michael Wyraz
michael.wy...@evermind.de wrote:
Hi Thiago,
Hi!
I didn't want to argue with you, just wanted to explain my opinion (and
understand yours). I can accept the decision to stay with private
methods althought I do not agree with you reasons
Hi,
for extending tapestrys internal service classes it's often required to
copy a lot of code because almost everything is private. Why not
changing it to protected to allow others to extend those classes?
Because it makes keeping backward-compatibility way harder and that's
very important
On Mon, 12 May 2014 05:54:31 -0300, Michael Wyraz
michael.wy...@evermind.de wrote:
Hi,
Hi!
Protected methods are normally not part of the official stable api. So
there's no difference for maintaining backward compatibility. I don't
see any drawback here
There's a huge difference. If
Hi,
for extending tapestrys internal service classes it's often required to
copy a lot of code because almost everything is private. Why not
changing it to protected to allow others to extend those classes?
Examples:
- to temporary fix https://issues.apache.org/jira/browse/TAP5-2219 I had
On Wed, 30 Apr 2014 06:43:53 -0300, Michael Wyraz
michael.wy...@evermind.de wrote:
Hi,
Hi!
for extending tapestrys internal service classes it's often required to
copy a lot of code because almost everything is private. Why not
changing it to protected to allow others to extend those
