L. David Baron wrote:
> However, I was thinking that we might want to change the way we
> implement IsFrameOfType slightly:
>
> * use virtual *inline* functions
> * make implementations call their base class
>
> So nsIFrame.h would have:
>
> virtual PRBool IsFrameOfType(PRUint32 aFlags) const {
> return !aFlags;
> }
>
> a frame that wanted to be SVG would then have:
>
> virtual PRBool IsFrameOfType(PRUint32 aFlags) const {
> return baseclass::IsFrameOfType(aFlags & ~(eSVG));
> }
>
> a frame that wanted to undo being a type its base class was would do:
>
> virtual PRBool IsFrameOfType(PRUint32 aFlags) const {
> return !(aFlags & (eReplaced)) && baseclass::IsFrameOfType(aFlags);
> }
>
> We might even want macros to do this.
>
> I'd hope that compilers could optimize this to the equivalent of what we
> do now (rewriting the whole thing in condensed form in derived classes).
Sounds good to me.
What was the reasoning behind IsFrameOfType/IsContentOfType having the
signature they have, instead of using methods that return a flags word?
The latter is a bit more expressive and may avoid multiple method calls
in some (hypothetical) cases.
> I'm also thinking that I want to make our use of typedefs like
> nsBlockFrameSuper more consistent (although many of them are macros).
> Though I may want to make them typedefs within the class, e.g.,
> nsBlockFrame::super_type.
Typedef within the class sounds good to me, but I might just call it Super.
Rob
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
