The overuse of final is largely irrelevant in impl packages. The reason
is that removing a final allows the class to remain binary compatible
and only items inside of the impl package should be extending the class.
In some cases, final helps ensure an implied contract. In other words,
if something is final, you know it's implemented nowhere else. In API's
I agree with Andy, final should be used only to enforce a contract that
should not (can not) change. Most commonly this is used on immutable
classes/api but it has some other uses.
Scott
Andy Schwartz wrote:
Hi Andrew -
On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
I wasn't suggesting blind removal.
Okay. The use of the word "most" gave me that impression. :-)
IMO final should rarely ever be used, for open source it almost never does
anyone any good.
Final should be used for its intended purpose. Sure, in some cases
final may be abused, but then those cases should be corrected. That
doesn't mean that final should rarely be used - it should be used when
appropriate.
Again, I don't see how open vs. closed source comes into play here.
Good API design is good API design, whether open or closed source.
I would suggest a renderer-by-renderer approach though, not method-by-method
as that would take too long to file that many bugs.
I am not sure I understand the difference between these approaches.
At some point somebody will need to evaluate specific methods to
determine whether changes are required.
Personally I prefer the approach that Blake alluded to, which is to
open things up as the need arises. (I may have missed it, but I don't
remember seeing the particular offending cases which triggered this
discussion.)
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.
I don't understand this at all. Why would anyone do that, vs. log an
issue, submit a patch, fix the problem, revel in the magic of open
source?
Is the issue here really that the renderers as a whole are considered
off-limits to subclassing, due to the fact that they are located in
trinidadinternal (not trinidadapi)?
Andy
