myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <>
Subject Re: [Trinidad] private / protected final methods in renderers
Date Thu, 10 Apr 2008 20:36:21 GMT
I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good. I would
suggest a renderer-by-renderer approach though, not method-by-method
as that would take too long to file that many bugs.

Right now Trinidad and facelets are by far the most inflexible open
source code I have worked with. Both over-use final and both assume
that out-of-the box behavior is enough fore everyone's needs. For
Trinidad renderers, many only expose encodeAll as protected then do
most of the work in private methods. As a result a person needing to
customize a renderer has to use copy & paste (generate an entirely new
renderer using the source of the core one) which really sucks for


On Thu, Apr 10, 2008 at 1:48 PM, Andy Schwartz
<> wrote:
> On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
>  <> wrote:
>  > +1 for:
>  >  - removing most final modifiers
>  >  - going from private to protected on most renderer methods
>  Not sure how much my opinion counts, since I am a new face around
>  here, but I am -1 on blindly removing most final modifiers, or
>  promoting most private methods to protected.  Methods may have been
>  intentionally marked as final by the Renderer author, eg. to enforce
>  the fact that the method is itself a convenience for some other method
>  which provides the actual implementation.  And many if not most of the
>  private methods are not necessarily good additions to the protected
>  API, since they were not designed with extensibility in mind.
>  I understand the desire for more flexibility, so if the community
>  feels this is important, then let's solve the problem.  However, I
>  don't think that the way to achieve this goal is by sacrificing basic
>  design principles.  If we want better protected APIs, then let's work
>  on adding them - arbitrarily removing most final/private modifiers
>  isn't the way to get there.
>  BTW, (referring back to early comments on this thread) I don't see how
>  this is an open vs. closed source issue.  The same API design
>  principles apply to both cases.
>  >  - and adding more customization hooks in the renderers
>  Now this sounds like a better idea.  In some cases this may mean
>  making existing final/private  methods non-final/protected, but we
>  should put some thought into which cases require this rather than
>  doing this in an arbitrary manner.
>  Andy

View raw message