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
