Generate toFooElement() functions from tagname data

Generate toFooElement() functions from tagname data

Introduce a "generateTypeHelpers" attribute that can be used in HTMLTagNames.in, SVGTagNames.in.
After landing this cl, toFooElement() style helpers will be added to HTML|SVGElementTypeHelpers.h.
We don't need to include "HTML|SVGNames.h" anymore, HTML|SVGElement.h just need to include
the HTML|SVGElementTypeHelpers.h

This attribute can support isFooElement() as well. A patch for the isFooElement() will be followed
if this patch is accepted.

Merge from WebKit r154965 and r155155.

BUG=N/A

[gyuyoung-inactive, 2013-09-09 05:36:53]

I would like to introduce a generation patch for toFooElement(). IMHO, we can
only generate toFooElement() for tags we only want using a
*generateTypeHelpers*. This patch was landed to WebKit as well. (r154965 and
r155155)

[tkent, 2013-09-09 05:53:39]

I'm slightly negative for this patch because
 - It can support only a part of elements
 - It uses reinterpret_cast<>.

https://codereview.chromium.org/23991004/diff/1/Source/core/scripts/make_name...
File Source/core/scripts/make_names.pl (right):

https://codereview.chromium.org/23991004/diff/1/Source/core/scripts/make_name...
Source/core/scripts/make_names.pl:591: print F "inline $class*
$castingHelper(Node* node) { ASSERT_WITH_SECURITY_IMPLICATION(!node ||
node->hasTagName(".$parameters{namespace}."Names::".$name."Tag)); return
reinterpret_cast<".$class."*>(node); }\n";
If we used reinterpret_cast<>, we should have a way to enforce Blink developers
to write class definitions which work well with reinterpret_cast.  I'm not sure
if it will be acceptable to the developers.

[tkent, 2013-09-09 06:37:51]

I found C++ standard didn't guarantee a base class address and a derived class
address are same. So, using reinterpret_cast in this purpose is not acceptable.

[gyuyoung-inactive, 2013-09-09 07:26:01]

On 2013/09/09 06:37:51, tkent wrote:
> I found C++ standard didn't guarantee a base class address and a derived class
> address are same. So, using reinterpret_cast in this purpose is not
acceptable.

ok, I'm trying to use static_cast<> instead of reinterpret_cast<>. It looks I
need to modify make_names.pl to use it.

>> - It can support only a part of elements

Could you let me know what is problem when we only support elements ? 


p.s. Now I'm in China, not Korea. So, my reply may be late.

[tkent, 2013-09-10 01:19:06]

On 2013/09/09 07:26:01, gyuyoung wrote:
> On 2013/09/09 06:37:51, tkent wrote:
> > I found C++ standard didn't guarantee a base class address and a derived
class
> > address are same. So, using reinterpret_cast in this purpose is not
> acceptable.
> 
> ok, I'm trying to use static_cast<> instead of reinterpret_cast<>. It looks I
> need to modify make_names.pl to use it.

It's not a simple replacement.  *ElementTypeHelpers.h needs to include all of
class definitions.

> >> - It can support only a part of elements
> 
> Could you let me know what is problem when we only support elements ? 

It's inconsistent.  If someone needs to add a missing toFooElement(), he would
waste some time to investigate why a part of toFooElement() is auto-generated
and the remaining is not.

[gyuyoung-inactive, 2013-09-10 03:21:25]

On 2013/09/10 01:19:06, tkent wrote:

> It's not a simple replacement.  *ElementTypeHelpers.h needs to include all of
> class definitions.

Yes, you're right. *ElementTypeHelpers.h should include all class definition to
use static_cast<>.

> On 2013/09/09 07:26:01, gyuyoung wrote:
> > On 2013/09/09 06:37:51, tkent wrote:
> It's not a simple replacement.  *ElementTypeHelpers.h needs to include all of
> class definitions.
> 
> > >> - It can support only a part of elements
> > 
> > Could you let me know what is problem when we only support elements ? 
> 
> It's inconsistent.  If someone needs to add a missing toFooElement(), he would
> waste some time to investigate why a part of toFooElement() is auto-generated
> and the remaining is not.

In my opinion, it is not too confuse to support auto-generated toFooElement()
only for elements. Because I believe someone will recognize what is
"generateTypeHelpers" role when he/she sees HTMLTagsNames.in or svgtags.in.

Anyway, it is a big problem to use static_cast<> instead of reinterpret_cast<>
in this case. :(

[gyuyoung-inactive, 2013-09-10 09:03:01]

> In my opinion, it is not too confuse to support auto-generated toFooElement()
> only for elements. Because I believe someone will recognize what is
> "generateTypeHelpers" role when he/she sees HTMLTagsNames.in or svgtags.in.
> 
> Anyway, it is a big problem to use static_cast<> instead of reinterpret_cast<>
> in this case. :(

We can't use reinterpret_cast<> for downcasting. Closed this cl.