The String package in Java is final. It's like this because it's a
fundimental non-mutable class and not having it final would cause headaches.
Below you mentioned not being able to create a good looking professional
application with Trinidad. If this is the case then perhaps we should
fix the issue with Trinidad in order to MAKE this possible. Extending
impl classes is NOT the answer.
I guess my problem with this whole thread is that, as Blake pointed out,
many of the API's in the Trinidad impl package are not well thought
out. Encouraging people to use them really limits the ability of the
renderkit to evolve. So what's the answer? Rethink the API's that are
needed, seek approval from the community, and move them to the API
package. I've done it with the ExternalContextUtils. Don't make the
mistake, however, of forcing Trinidad into supporting api's that are not
well thought out.
Scott
Andrew Robinson wrote:
final should only be used if extending a function would cause it to
break. Forcing someone to call the super method is something that
should be in JavaDoc, not as a final keyword. Final's true purpose is
to create unchangeable member vars and also protect code. For example,
if I have commercial software that checks a license, it should be
final. Basically, if you don't have a reason to use final, don't use
it.
Final is often used in closed source because there are support issues.
By making something final, it is easier to debug. In the open source
world customers can debug into the code themselves to see what
documentation may not be clear about.
Python goes further, it has no final, everything is mutable. The idea
is to give ppl. the power they need and let them shoot themselves in
the foot if they want to.
This isn't just a matter of principle. I challenge you to author a
real world application with Trinidad, and let me know if it is
possible while letting it look professional. I found that it is not,
it is very rigid, to the point of lack of usability. Many times I
would create my own components and my own renderers because the core
ones just didn't do what I needed them to do and the renderers were
all private & final.
Take for example the table which always renders the select all and
unselect all at the top of the table and has no way to customize it.
An argument could easily be made to enhance the component API to add
these configurable points, but there is no way to anticipate them all.
If the renderer was more extendable this would be possible.
-Andrew
On Thu, Apr 10, 2008 at 3:34 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
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
