-1 - I agree with Andy and Max for the reasons Matthias stated. Classes
in the Trinidad impl are not to be used outside of trinidad itself.
Only items in the API need to worry about extension outside of the
renderkit. As such, I think leaving things status quo is probably
prudent. Because this *IS* an OpenSource project, I suppose the
community (or interested parties) could propose adding some of these
components to the API, but I wholeheartedly disagree that we need to
change the impl because someone wants to extend it.
Andrew Robinson wrote:
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
maintenance.
-Andrew
On Thu, Apr 10, 2008 at 1:48 PM, Andy Schwartz
<[EMAIL PROTECTED]> wrote:
On Thu, Apr 10, 2008 at 1:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> 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
