IsElement() and nsIElement

[Boris Zbarsky]

So I'm looking at creating a non-virtual IsElement().

While examining the callsites, it seems like a lot of the use is in
assertions in places where we want to be sure we're dealing with an
Element node. Would it make sense to create an nsIElement for now,
sitting between nsIContent and nsGenericElement, to just enforce this
sort of invariant in function signatures? Or should we just make such
functions take nsGenericElement arguments? Or maybe that plus rename
nsGenericElement to mozilla::dom::Element or something?

-Boris

[Ehsan Akhgari]

Post by Boris Zbarsky
So I'm looking at creating a non-virtual IsElement().
While examining the callsites, it seems like a lot of the use is in
assertions in places where we want to be sure we're dealing with an Element
node.  Would it make sense to create an nsIElement for now, sitting between
nsIContent and nsGenericElement, to just enforce this sort of invariant in
function signatures?  Or should we just make such functions take
nsGenericElement arguments?  Or maybe that plus rename nsGenericElement to
mozilla::dom::Element or something?

I've been frustrated more than once because we don't provide any
obvious way of passing elements around, instead of passing an
nsIContent and letting the function ensure that it's getting an
element. However, I think passing elements as nsGenericElement is a
mistake, because it's a concerete class with lots of implementation
details, which not all callers would need. Hence, I think adding an
nsIElement makes a lot of sense.

--
Ehsan
<http://ehsanakhgari.org/>

[j***@gmail.com]

Post by Boris Zbarsky
So I'm looking at creating a non-virtual IsElement().
While examining the callsites, it seems like a lot of the use is in
assertions in places where we want to be sure we're dealing with an
Element node.  Would it make sense to create an nsIElement for now,
sitting between nsIContent and nsGenericElement, to just enforce this
sort of invariant in function signatures?  Or should we just make such
functions take nsGenericElement arguments?  Or maybe that plus rename
nsGenericElement to mozilla::dom::Element or something?
-Boris

I'm not a fan of the idea of spreading nsGenericElement around too
widely, but if we rename it mozilla::dom::Element I'd be ok with that.
But Ehsan does have a point in that it does contain a lot of internals
that are never really meant for code outside of the guts of our
elements, but those could of course be made protected etc. So I think
if we pay attention to that and protect the internals, it could work,
but writing a separate Element (or nsIElement) class would work for me
as well.

[Boris Zbarsky]

Post by j***@gmail.com
I'm not a fan of the idea of spreading nsGenericElement around too
widely, but if we rename it mozilla::dom::Element I'd be ok with that.
But Ehsan does have a point in that it does contain a lot of internals
that are never really meant for code outside of the guts of our
elements, but those could of course be made protected etc. So I think
if we pay attention to that and protect the internals, it could work,
but writing a separate Element (or nsIElement) class would work for me
as well.

OK. I'm going to make an (empty for now) mozilla::dom::Element sitting
between nsGenericElement and nsIContent. Then we can hoist things to
Element as desired, or wholesale rename nsGenericElement to
mozilla::dom::Element at some point.

-Boris

[Boris Zbarsky]

Post by Ehsan Akhgari
I've been frustrated more than once because we don't provide any
obvious way of passing elements around, instead of passing an
nsIContent and letting the function ensure that it's getting an
element. However, I think passing elements as nsGenericElement is a
mistake, because it's a concerete class with lots of implementation
details, which not all callers would need.

Here's the thing. One of the long-term goals here is to get rid of
virtual dispatch at callsites that know they have an element, as much as
possible. That means that either we need to put things that we expect
to be commonly called on nsIElement and make them non-virtual or
something along those lines. That might not lead to us putting too much
in the way of implementation details on nsIElement, but it's worth
keeping in mind.

-Boris