Re: [Trinidad] private / protected final methods in renderers

[Max Starets]

I completely agree with Andy, so I am -1 for removing protected on most renderer methods as well. Max Andy Schwartz 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