The reason is that each time we make one of these methods protected, we
have to guarantee that we will maintain the semantics of that hook until
the end-of-time or risk breaking users of that hook. By slowly opening
up the api we get the developers to tell us what they need and can weigh
the benefit against the support cost. If the hooks don't require that
super be called, in many ways, it is safer to completely override the
function.
This is the general issue of the competing desires to make it easy to
tweak a renderer by subclassing without needing to completely replace it
vs. a desire to be able to change the Renderer implementation without
breaking subclassers. I actually think that we went too far in
providing lots of subclasser knobs in Trinidad, but that's just my opinion.
-- Blake Sullivan
Cristi Toth said the following On 4/9/2008 5:23 PM PT:
Hi guys,
A lot of Trinidad renderers have some "override useful" methods as
private or protected final.
This makes customizing renderers a nasty job.
- first these methods obviously can't be overriden
- then when trying to override some public/protected methods,
it's hard because they use other private methods that you can't use
in your overriden method
I assume this come from the fact that Trinidad wasn't open-source in
its origins... or?
Do we still have reasons to keep it this way?
IMO we could make those protected final "override useful" methods to
protected
and the private methods used in those methods, make them protected final.
What's you opinion on this?
Regards,
--
Cristi Toth
-------------
Codebeat
www.codebeat.ro <http://www.codebeat.ro>
