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 >
