Andrew Robinson said the following On 4/11/2008 8:53 AM PT:
> What I mean by this is that rendereds should make an effort to expose
> functionality even if it isn't thought through
I am not a fan of this. If people want to put in the effort to think
through APIs that they expose on their renderers, then +1. But big -1
from me for exposing APIs haphazardly.
My point is that protected in the trinidad-impl.jar is not an API that
is exposed. Since it is not an API, therefore it does not have to be
designed as such.
Let me give you a valid use case (valid as it has happened to me while
working on a project, not Trinidad, but similar open source issue):
1) Company decides to adopt Trinidad for a project
2) They are either (a) crunched for time or (b) need to get a release out
3) From mgmt, they are told they have to implement a feature
4) Trinidad has no way to support this feature, but the current
renderer has a method that would allow me to do it if it were
protected
5) So assuming #3, the method is protected and in the trinidad-impl.jar
6) I extend the method, hacking the renderer and get the code to work
as required by my company and my customers.
7) We ship on this code to get it out the door
8) In the meantime, I create a JIRA issue to expose the functionality I require
9) It goes through weeks of debate (operating on recent Trinidad
experience on this comment) and finally 2 days to 5 months later makes
it into a SNAPSHOT build
10) My company has a policy to only use released versions, so I wait
and wait for the release (which is much better for Trinidad users that
Tomahawk which has less than yearly release cycles)
Rhetorical question--why would a company have such a policy? Because
they want some guarantee that new Trinidad releases have gone through
some set of testing and won't break their code. A pragmatic company
would say sure, ship the hacked version. A less pragmatic company would
say--just copy the code in the Renderer and then hack that.
A few more comments.
What happens if the code doesn't already have exactly the hook point you
need? What are you going to do--hack in the hook point so that you can
override it?
One of the points that I believe that Cristi touched on is that deep
inheritance hierarchies with large numbers of hooks and lots of
delegation to other private code make it difficult to both figure out
what is going on and difficult to actually copy the code for modification.
One of the solutions is to make sure that we have enough public
rendering utilities and that possibly some of the important aspects of
delegating renderers and that it is possible to use the labeling
renderer support without needing direct access to that Renderer.
11) When it finally becomes API, I port my code from the hack of
subclassing the code to the new API
So as you can see, it was never my intention to treat the usage of the
protected method as a solution, but a temporary way to get my code to
work. Asking users to log bugs and wait for discussion and then
implementation and then a release is simply not feasible for many
companies that need to get software out the door.
As noted above, this is by the company's choice. They could have
shipped the hacked version. The could have copied the code and then
modified it. They did neither.
So when I say #3 then #2, I mean to allow people to get their code out
quickly and then go through the proper channels to improve the code.
Saying #2 only is just not feasible for companies to meet deadlines
and many companies will not permit you to change open source code and
ship the changed versions (some afraid of licenses,
There is no problem with the Apache license here, so the companies are
being silly with Regards to Trinidad
some afraid of
maintenance).
Your proposal that we make everything protected and tell the consumers
to hope for the best on upgrades does not decrease their maintenance burden.
-- Blake Sullivan
I fully agree that #2 is the solution though and even that we need to
make some part of the trinidad rendering in the API, because I
strongly feel that only having components in the API is just not
customizable enough, and I don't think that components with 300
attributes and facets is the way to go.
