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 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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
