Stephen Friedrich said the following On 4/13/2008 11:26 PM PT:
Blake, in general you point of view is a very theoretical one from a high
ebony tower. Do you say so in english? ;-)
In English, it is usually "ivory tower", but, if you think that I'm
evil, "ebony tower" might be more approriate.
In real life those private methods do make using Trinidad more cumbersome
that it needs to be.
For example it is currently not possible to make a simple change like
moving
"*" _behind_ field labels.
I agree that there should be a well defined contract how to adjust
behaviour
- in theory. Practically speaking to fix that little issue, I had to
understand trinidad sources, create a patch and recompile that whole damn
thing.
Not really a better solution, isn't it?
This is a fine example:
For this to be easy, the developer would have needed to have already
added a protected hook to control where the required field indicator is
located. Yet, if he had that much foresight, why didn't he make the
property skinnable? Let's say that he did have the foresight, you
overrode his hook and now he realizes that the property should be
skinnable. Your renderer subclass doesn't honor the skinning key. Not
the end of the world for your Renderer in this case.
Note that in order to find the protected hook to use in the first place
and verify that its use would not cause some other unexpected result,
you would almost certainly need to understand the source.
I agree that making a one-off patch to the sources is a pain, but while
some of the proposals will decrease the likelihood that any particular
change requires hacking on the base code, in many cases, the hook you
want simply won't exist in the base code, because we only put the hooks
in that we needed to solve the particular problems we were experiencing
at that point in time. Therefore, if you want to extend a Trinidad
Renderer class, even in an unsupported fashion, you need to accept that
you might need to hack.
-- Blake Sullivan
If you don't personally agree to go through each and every source file in
Trinidad and fix those issues with hardcoded, unchangeable behaviour,
then
please have some understanding for the purpose of the request.
It goes without saying that overriding protected methods in trinidad
interal
sources can break if you blindly update to the next trinidad version.
Yet, I better like to have that documented in my app, than having to
document
"well, and then you have to download trinidad sources, make these and
that
patches, check if they are still compatible with the new trinidad
version,
recompile the lib and ship with that modified copy of trinidad".
Blake Sullivan wrote:
Andrew Robinson said the following On 4/10/2008 1:36 PM PT:
I wasn't suggesting blind removal. IMO final should rarely ever be
used, for open source it almost never does anyone any good.
Really. Why would good programming practice in the closed source
world be bad programming practice in open source? If anything, it is
easier to change these restrictions in open source, if necessary.
What you are really saying is that you disagree with the decisions
made by the class designers with respect to the trade-offs between
intertwining the subclasses and superclasses and the convenience of
tweaking implementation.
There is a real cost to the maintainability and evolution of the
superclasses if they are burdened with huge numbers of protected
hooks. Especially if those hooks became protected without the
necessary work to nail down their precise contract.
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.
Functions are private or final because the class designer because
those aren't designed extension points. I suspect that Trinidad and
Facelets are being honest about this. I would be suspicious of a
class with huge numbers of protected methods--it is doubtful that all
of the possible interactions have actually been considered.
One of the advantages of open source is that it is easy to test
opening up particular pieces and ask for your change to be approved.
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.
On the other hand, the renderer author gains isolation and the
superclasses don't need to add every single hook that any possible
subclasser might want.
If there really are huge chunks of interesting code that should be
shared in this case, they can be broken out into utilities and shared
that way.
-- Blake Sullivan
-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
