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 > > > > > >
