if we make is* final that means you can no long pull information which will
lead to ugly code. components that have dynamic * attribute will have to
override onattach/onbeforerender and push state in there - which is much
uglier then simply overriding is*.
-igor
On 8/14/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> On 8/14/07, Kent Tong <[EMAIL PROTECTED]> wrote:
> > Eelco Hillenius <[EMAIL PROTECTED]> writes:
> >
> > > > Can't you have an onSetRequired() callback? Or would that be even
> nastier?
> >
> > I thought you had gone through this issue?
>
> Hey, Al wrote that line, not me :)
>
> If a child class provides
> > a onSetRequired() but a grand child wants to override it, it still
> > has to override it. Then why not just let the child and grand child
> > override setRequired()?
> > I think onXXX() callbacks only make sense when the effect can't be
> > achieved with simple method override, eg, cases like:
> >
> > void foo() {
> > do something;
> > onXXX();
> > do something;
> > onYYY();
> > do something;
> > }
>
> I agree. In favor of onXX though is that it would be easier to
> recognize that it is there for overriding and that users don't have to
> call super (though the disadvantage of that can be seen in our
> struggles with onAttach etc).
>
> > > That would be exactly what I want, though bloats our already not tiny
> > > API, but the main problem then still is that users can override
> > > isRequired.
> >
> > Why not make isRequired() final?
>
> I think I would be ok with that. Though a similar case, isVisible, is
> just to convenient to make final. So I can imagine there will be users
> who rather override isVisible. Dunno, we could vote on it I guess.
>
> Eelco
>
