On 12/7/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Another example is Link with a label inside. I'm starting to get irritated with the fact that even though a label rendering was requested as part of it's default behavior, and at least some people were pro that, it ended in a stale mate again, and that even the basic facility for letting people do that themselves (letting them override onComponentTagBody) is yet again a point of debate.
And this is exactly why I am not +1. This is a covert attempt to get your way, even though the previous vote stranded. The developer community needs to be in line for such a change. This didn't happen with the previous vote, so what makes you think this has changed?
I don't believe we have to be that strict on these methods anymore.
I think some disagree here, as can be seen from the mixed reactions to your proposal.
They served our purposes for protecting ourselves against opening up too soon well, and as you can see from the history of opening up these methods, there usually have been cases where it made perfect sense, but we just didn't think about the use case before.
Therefore we ask with each opening of the API for a usecase. In your proposal the only usecase you give is that "it is time". Or your frustration that a previous attempt stranded. In the onComponentTag change, I gave a usecase: memory consumption of AttributeModifiers. Everything in onComponentTag can be achieved using AttributeModifiers. However, they cost memory. If a component is used a lot, then it is beneficial to be able to override this method, and use it as a low-cost AttributeModifier. However, this doesn't imply I want full control for this method on all components. For the record, I could manage this using the existing non-final components. Martijn
