Generally agreed. With public APIs I've learnt to be stronger on
making things private as it tends to only come back to bite you if you
try to over think it; and when it's public you have no ability to
identify all the use cases so you end up in legacy hell.

I just fix the bugs though - I wasn't an original developer :) I
suspect their focus was strongly on implementing the spec and less on
the implementation classes themselves.


On Sat, Jul 11, 2009 at 1:32 AM, Stuart Thiel<> wrote:
> Hello Henri,
> Yes, that would solve my immediate problem. It is a bit of a one-off hack,
> though. The follow-through would be to take a look at all the classes and
> identify areas where "hooks" like that would be desirable.
> It is perhaps a difference in philosophies of programming, but my preference
> is generally to use protected methods instead of private methods (and avoid
> final methods at all costs), and that would be my preferred approach here (I
> don't know your direct involvement thusfar into how things are). However,
> consistency is also good to see in a project, and it's not my show, so I'm
> less inclined to prosthelytize on how to "do it right". I'd be glad to go on
> at length as to why I think the protected methods approach would be best,
> but will only do so upon request.
> Stuart
> Henri Yandell wrote:
>> I didn't explain myself well.
>> Basically I would insert reconfigureFormatter(NumberFormat/DateFormat)
>> inside doEndTag. By default it would nothing.
>> On Fri, Jul 10, 2009 at 5:03 AM, Stuart Thiel<>
>> wrote:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to