myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Starets <>
Subject Re: [Trinidad] private / protected final methods in renderers
Date Thu, 10 Apr 2008 19:56:01 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
I completely agree with Andy, so I am -1 for removing protected<br>
on most renderer methods as well.<br>
Andy Schwartz wrote:
  <pre wrap="">On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
<a class="moz-txt-link-rfc2396E" href="">&lt;;</a>
  <blockquote type="cite">
    <pre wrap="">+1 for:
 - removing most final modifiers
 - going from private to protected on most renderer methods
  <pre wrap=""><!---->
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.

  <blockquote type="cite">
    <pre wrap=""> - and adding more customization hooks in the renderers
  <pre wrap=""><!---->
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.


View raw message