You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Michael Wyraz <mi...@evermind.de> on 2014/05/12 10:54:31 UTC
Re: Make more fields/methods of service classes protected
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 for the project.
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
> Not to mention that protected fields are something to be avoided in OOP.
That's true for fields in some cases, right. But IMO does not apply to
most methods. Especially in service classes where certain functionality
is moved to methods - here one of the most powerful oop concepts is to
override those methods to change behaviour. Of course the most advanced
way would be to have an abstract basic implementation of each service
plus implementions of each aspect of that service. But that would be
much overhead in most cases.
> In addition, you can use advise or overriding for dealing with most
> problems.
Sure, one can use advice to achieve basically the same. But this will
cause much more problems:
- same backward compatibility issue as if you would override internal
methods
- but you would not get a compiler message about this. Instead the
behaviour would silently fall back to the default. Bad thing!
- Much more (and much less readable) complex code for trivial changes.
Overriding is only a solution if you have a drop-in replacement for a
service. That means in most cases that you have to copy a service and to
a change there.
Another similar problem are final methods. Last week we created a few
custom form field components and we started with extending AbstractField
which contains most required stuff. All was fine until we wanted to
change the label behaviour:
- if a "label" parameter is bound, use this
- otherwise check a custom service
- otherwise check the bound parameter for a label annotation
- otherwise use defaultLabelProvider
But... defaultLabel() is package protected + final. So we cannot:
- override the method
- test if the parameter is bound (bound is always true when a
defaultParam() method exists)
So I had to copy the whole AbstractField component to do the simple
change. Alternatively I'd have to change/decorate
ComponentDefaultProvider but this would change the behaviour in all
components, not just those special ones.
So how should one solve such problems if so many methods are private (or
package protected) and/or final?
Kind regards,
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Make more fields/methods of service classes protected
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 13 May 2014 05:25:22 -0300, Michael Wyraz
<mi...@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 ^^
I'm more than happy to discuss anything related to Tapestry, even the
reasons, in which the past and image of Tapestry are a huge factor.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Make more fields/methods of service classes protected
Posted by Michael Wyraz <mi...@evermind.de>.
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.
> Tapestry internal service implementations and all services (unless
> stated otherwise, as Autocomplete) were written with the assumption
> that they won't be subclasses. They're not part of the public API and
> shouldn't be used directly. Period.
>
> Why don't you post here what changes of behavior you want to be done
> in Tapestry sources and, if we all agree, have it done in the source
> code itself instead of asking us for something too broad as changing
> methods and fields visibilities?
>
--
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.wyraz@evermind.de
HRB: 21586
Amtsgericht Leipzig
Geschäftsführer:
Christoph Klemm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Make more fields/methods of service classes protected
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Mon, 12 May 2014 05:54:31 -0300, Michael Wyraz
<mi...@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 you put anything visible for users
(developers), they'll end up using it. If there's someone using it, we
just cannot change it without the risk of breaking users' code.
From an OOP point of view, protected methods are part of the public API.
You're asking from a large change in Tapestry's philosophy. I really doubt
other committers would agree, and I don't. I'm just trying to explain why.
>> Not to mention that protected fields are something to be avoided in OOP.
> That's true for fields in some cases, right. But IMO does not apply to
> most methods. Especially in service classes where certain functionality
> is moved to methods - here one of the most powerful oop concepts is to
> override those methods to change behaviour. Of course the most advanced
> way would be to have an abstract basic implementation of each service
> plus implementions of each aspect of that service. But that would be
> much overhead in most cases.
Tapestry internal service implementations were written with the assumption
that they won't be subclasses. They're not part of the public API and
shouldn't be used directly. Period.
>> In addition, you can use advise or overriding for dealing with most
>> problems.
> Sure, one can use advice to achieve basically the same. But this will
> cause much more problems:
> - same backward compatibility issue as if you would override internal
> methods
You shouldn't override internal methods already. Again, Tapestry service
implementations are *not* meant to be subclassed.
> - but you would not get a compiler message about this. Instead the
> behaviour would silently fall back to the default. Bad thing!
> - Much more (and much less readable) complex code for trivial changes.
>
> Overriding is only a solution if you have a drop-in replacement for a
> service. That means in most cases that you have to copy a service and to
> a change there.
>
>
> Another similar problem are final methods.
Tapestry internal service implementations and all services (unless stated
otherwise, as Autocomplete) were written with the assumption that they
won't be subclasses. They're not part of the public API and shouldn't be
used directly. Period.
Why don't you post here what changes of behavior you want to be done in
Tapestry sources and, if we all agree, have it done in the source code
itself instead of asking us for something too broad as changing methods
and fields visibilities?
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org