myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Sullivan <>
Subject Re: [Trinidad] private / protected final methods in renderers
Date Thu, 10 Apr 2008 22:12:10 GMT
Andrew Robinson said the following On 4/10/2008 1:36 PM PT:
> I wasn't suggesting blind removal. IMO final should rarely ever be
> used, for open source it almost never does anyone any good.
Really. Why would good programming practice in the closed source world 
be bad programming practice in open source?  If anything, it is easier 
to change these restrictions in open source, if necessary.

What you are really saying is that you disagree with the decisions made 
by the class designers with respect to the trade-offs between 
intertwining the subclasses and superclasses and the convenience of 
tweaking implementation.

There is a real cost to the maintainability and evolution of the 
superclasses if they are burdened with huge numbers of protected hooks.  
Especially if those hooks became protected without the necessary work 
to  nail down their precise contract.
>  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.
Functions are private or final because the class designer because those 
aren't designed extension points.  I suspect that Trinidad and Facelets 
are being honest about this.  I would be suspicious of a class with huge 
numbers of protected methods--it is doubtful that all of the possible 
interactions have actually been considered.

One of the advantages of open source is that it is easy to test opening 
up particular pieces and ask for your change to be approved.
>  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
> maintenance.
On the other hand, the renderer author gains isolation and the 
superclasses don't need to add every single hook that any possible 
subclasser might want.

If there really are huge chunks of interesting code that should be 
shared in this case, they can be broken out into utilities and shared 
that way.

-- Blake Sullivan
> -Andrew
> 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