Well I think we don't see the problem in the same way.
What does good design mean in this case ...!?
Making some methods protected and remove the final for others doesn't
hurt Trinidad itself at all.
So you can't say this is bad design.
If the bad design refers to what we offer the clients, than this is
definitely wrong.
Because a quite a lot of clients that me or some of my collaborators
have interacted with,
have complained a lot about Trinidad code that's so CLOSED !!!
Many said that instead of trying a small feature to the trinidad table,
you better take the Tomahawk one, and add all the feature you need on it.
It's easier and cleaner.
The faces-config allows you to override any renderer for any
component, right !?
So renderers are meant to be overriden. (by the JSF spec)
This is the beauty of JSF, because it's so flexible and customizable.
How do you expect to override Trinidad renderers?
Copying all the code and make some small changes?
Imagine that overriding some behaviour of some larger renderers,
you have to override the whole renderer hierarchy (i.w.
LabelAndMessageRenderer).
Between duplicating the whole renderer code
and just having some protected renderer methods,
which sounds better in design?
If we talk about backwards compatibilty,
then imagine a whole duplicated renderer which isn't aware of any
other updated renderers...
And if a custom renderer developer gets a compile error after an update,
I assume it won't take him to much time to fix it...
If a renderer is not in the API, this means that it shouldn't be
overriden !?
Let's think a bit out of the box and try to figure what's best for the
client.
Because that's what matters most...
regards,
On Thu, Apr 10, 2008 at 11:34 PM, Scott O'Bryan <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
The overuse of final is largely irrelevant in impl packages. The
reason is that removing a final allows the class to remain binary
compatible and only items inside of the impl package should be
extending the class.
In some cases, final helps ensure an implied contract. In other
words, if something is final, you know it's implemented nowhere
else. In API's I agree with Andy, final should be used only to
enforce a contract that should not (can not) change. Most
commonly this is used on immutable classes/api but it has some
other uses.
Scott
Andy Schwartz wrote:
Hi Andrew -
On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I wasn't suggesting blind removal.
Okay. The use of the word "most" gave me that impression. :-)
IMO final should rarely ever be used, for open source it
almost never does
anyone any good.
Final should be used for its intended purpose. Sure, in some
cases
final may be abused, but then those cases should be corrected.
That
doesn't mean that final should rarely be used - it should be
used when
appropriate.
Again, I don't see how open vs. closed source comes into play
here.
Good API design is good API design, whether open or closed source.
I would suggest a renderer-by-renderer approach though,
not method-by-method
as that would take too long to file that many bugs.
I am not sure I understand the difference between these
approaches.
At some point somebody will need to evaluate specific methods to
determine whether changes are required.
Personally I prefer the approach that Blake alluded to, which
is to
open things up as the need arises. (I may have missed it, but
I don't
remember seeing the particular offending cases which triggered
this
discussion.)
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.
I don't understand this at all. Why would anyone do that, vs.
log an
issue, submit a patch, fix the problem, revel in the magic of open
source?
Is the issue here really that the renderers as a whole are
considered
off-limits to subclassing, due to the fact that they are
located in
trinidadinternal (not trinidadapi)?
Andy
--
Cristi Toth
-------------
Codebeat
www.codebeat.ro <http://www.codebeat.ro>
