Re: [webkit-dev] Type checking / casting helpers

[Yong Li]

Downcast is the old good name.

"cast" is so vague. I would assume cast(B) means: { return (A)B; }

Yong Li

From: Darin Adler
Sent: ‎10/‎3/‎2014 3:16 AM
To: WebKit Development
Subject: Re: [webkit-dev] Type checking / casting helpers

I suggested the name; my inspiration was the boost::polymorphic_downcast 
function template. I also like the way a name ending with the word cast fits in 
with the family of static_cast, dynamic_cast, and reinterpret_cast.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Type checking / casting helpers

[Darin Adler]

I suggested the name; my inspiration was the boost::polymorphic_downcast 
function template. I also like the way a name ending with the word cast fits in 
with the family of static_cast, dynamic_cast, and reinterpret_cast.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Type checking / casting helpers

[Sam Weinig]

That also sounds like reasonable behavior for something called cast<>() to me. 

Sent from my iPhone

> On Oct 2, 2014, at 5:01 PM, Benjamin Poulain  wrote:
> 
> downcast<> fails if you do a useless cast/upcast.
> 
> Benjamin
> 
>> On 10/2/14, 4:47 PM, Sam Weinig wrote:
>> This all looks wonderful!
>> 
>> One question though, why downcast<>(…)? Will we be adding an upcast<>()
>> function? Since the answer is probably no, could we just call this
>> cast<>(…)?
>> 
>> - Sam
>> 
>>> On Sep 25, 2014, at 11:11 AM, Chris Dumez >> > wrote:
>>> 
>>> Hi all,
>>> 
>>> I started working on automatically generating the type *casting*
>>> helpers for HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until
>>> now, we were generating only the type *checking* helpers using
>>> make_names.pl (e.g. isHTMLDivElement()). The type *casting* helpers
>>> had to be manually defined using NODE_TYPE_CASTS() macro.
>>> 
>>> The type casting helpers are now automatically generated for most
>>> types. Part of the solution involved using a templated function for
>>> type casting because the types are forward-declared and we needed to
>>> do a static_cast<>() (a reinterpret_cast<>() could be used with
>>> forward declarations but wouldn’t be safe due to multiple inheritance).
>>> 
>>> I initially had macros in place so that toHTMLDivElement() would still
>>> work and would be equivalent to downcast(). The
>>> feedback I received is that we should get rid of these macros and just
>>> use is() / downcast() everywhere.
>>> The new style is very close to C++’s is_class() and Boost’s
>>> polymorphic_downcast().
>>> 
>>> I actually started updating the code to do this but I should have
>>> emailed webkit-dev about this beforehand. I apologize for sending this
>>> message a bit late.
>>> 
>>> Please let me know if you have feedback / concerns / questions about
>>> this change. I hope that this email gives you a better understanding
>>> of why I am making this change.
>>> 
>>> As I said before, the code base is not fully ported yet so the current
>>> situation is not necessarily pretty. I will try and go through the
>>> transition as fast as I can, provided that people don’t raise any
>>> concerns about this.
>>> 
>>> Please also note that these new helpers still catch unnecessary type
>>> checks / casts. As a matter of fact, those are now caught at build
>>> time instead of linking time and should give you a nice “Unnecessary
>>> type check” / “Unnecessary type cast” static assertion.
>>> 
>>> Also note that the plan is to get rid of TYPE_CAST_BASE() macro
>>> entirely and extend is<>() / downcast<>() to all types, not just Nodes.
>>> 
>>> Kr,
>>> --
>>> Chris Dumez - Apple Inc.
>>> Cupertino, CA
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org 
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Type checking / casting helpers

[Benjamin Poulain]

downcast<> fails if you do a useless cast/upcast.

Benjamin

On 10/2/14, 4:47 PM, Sam Weinig wrote:

This all looks wonderful!

One question though, why downcast<>(…)? Will we be adding an upcast<>()
function? Since the answer is probably no, could we just call this
cast<>(…)?

- Sam


On Sep 25, 2014, at 11:11 AM, Chris Dumez mailto:cdu...@apple.com>> wrote:

Hi all,

I started working on automatically generating the type *casting*
helpers for HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until
now, we were generating only the type *checking* helpers using
make_names.pl (e.g. isHTMLDivElement()). The type *casting* helpers
had to be manually defined using NODE_TYPE_CASTS() macro.

The type casting helpers are now automatically generated for most
types. Part of the solution involved using a templated function for
type casting because the types are forward-declared and we needed to
do a static_cast<>() (a reinterpret_cast<>() could be used with
forward declarations but wouldn’t be safe due to multiple inheritance).

I initially had macros in place so that toHTMLDivElement() would still
work and would be equivalent to downcast(). The
feedback I received is that we should get rid of these macros and just
use is() / downcast() everywhere.
The new style is very close to C++’s is_class() and Boost’s
polymorphic_downcast().

I actually started updating the code to do this but I should have
emailed webkit-dev about this beforehand. I apologize for sending this
message a bit late.

Please let me know if you have feedback / concerns / questions about
this change. I hope that this email gives you a better understanding
of why I am making this change.

As I said before, the code base is not fully ported yet so the current
situation is not necessarily pretty. I will try and go through the
transition as fast as I can, provided that people don’t raise any
concerns about this.

Please also note that these new helpers still catch unnecessary type
checks / casts. As a matter of fact, those are now caught at build
time instead of linking time and should give you a nice “Unnecessary
type check” / “Unnecessary type cast” static assertion.

Also note that the plan is to get rid of TYPE_CAST_BASE() macro
entirely and extend is<>() / downcast<>() to all types, not just Nodes.

Kr,
--
Chris Dumez - Apple Inc.
Cupertino, CA




___
webkit-dev mailing list
webkit-dev@lists.webkit.org 
https://lists.webkit.org/mailman/listinfo/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Type checking / casting helpers

[Sam Weinig]

This all looks wonderful!

One question though, why downcast<>(…)? Will we be adding an upcast<>() 
function? Since the answer is probably no, could we just call this cast<>(…)?

- Sam

> On Sep 25, 2014, at 11:11 AM, Chris Dumez  wrote:
> 
> Hi all,
> 
> I started working on automatically generating the type casting helpers for 
> HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until now, we were 
> generating only the type checking helpers using make_names.pl (e.g. 
> isHTMLDivElement()). The type casting helpers had to be manually defined 
> using NODE_TYPE_CASTS() macro.
> 
> The type casting helpers are now automatically generated for most types. Part 
> of the solution involved using a templated function for type casting because 
> the types are forward-declared and we needed to do a static_cast<>() (a 
> reinterpret_cast<>() could be used with forward declarations but wouldn’t be 
> safe due to multiple inheritance).
> 
> I initially had macros in place so that toHTMLDivElement() would still work 
> and would be equivalent to downcast(). The feedback I 
> received is that we should get rid of these macros and just use 
> is() / downcast() everywhere.
> The new style is very close to C++’s is_class() and Boost’s 
> polymorphic_downcast().
> 
> I actually started updating the code to do this but I should have emailed 
> webkit-dev about this beforehand. I apologize for sending this message a bit 
> late.
> 
> Please let me know if you have feedback / concerns / questions about this 
> change. I hope that this email gives you a better understanding of why I am 
> making this change.
> 
> As I said before, the code base is not fully ported yet so the current 
> situation is not necessarily pretty. I will try and go through the transition 
> as fast as I can, provided that people don’t raise any concerns about this.
> 
> Please also note that these new helpers still catch unnecessary type checks / 
> casts. As a matter of fact, those are now caught at build time instead of 
> linking time and should give you a nice “Unnecessary type check” / 
> “Unnecessary type cast” static assertion.
> 
> Also note that the plan is to get rid of TYPE_CAST_BASE() macro entirely and 
> extend is<>() / downcast<>() to all types, not just Nodes.
> 
> Kr,
> --
> Chris Dumez - Apple Inc.
> Cupertino, CA
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JavaScriptCore subclass native class created with JSClassCreate in javascript code

[Geoffrey Garen]

…Yet another option is to insert Function.prototype into the TestClass 
prototype chain.

Geoff

> On Oct 2, 2014, at 4:37 PM, Geoffrey Garen  wrote:
> 
> You’ll need to manually copy Function.prototype.apply to the TestClass 
> prototype.
> 
> Another option is “Function.prototype.apply.call(TestClass, this, arguments)”.
> 
> Geoff
> 
>> On Oct 2, 2014, at 8:26 AM, Moritz Moeller > > wrote:
>> 
>> Hi,
>> 
>> I’ve created a javascript class in native code (i.e. JSClassCreate, 
>> JSObjectMakeConstructor etc.) and want to subclass this class in javascript.
>> 
>> So pretty much:
>> 
>> JSClassDefinition classDef = kJSClassDefinitionEmpty;
>> classDef.className = "TestClass";
>> classDef.getProperty = class_getProperty;
>> classDef.setProperty = class_setProperty;
>> JSClassRef classRef = JSClassCreate(&classDef);
>> JSObjectRef constructor = JSObjectMakeConstructor(ctx, gClassRef, 
>> class_constructor);
>> JSObjectSetProperty(ctx, JSContextGetGlobalObject(ctx), 
>> JsString("TestClass"), constructor, 0, NULL);
>> 
>> class_constructor does:
>> return JSObjectMake(ctx, classRef, NULL);
>> 
>> This works, so I can do
>> var test = new TestClass();
>> test.field = 1;
>> 
>> and both class_constructor and class_setProperty is called.
>> 
>> Now I’m trying to subclass the TestClass:
>> function SubClass()
>> {
>> TestClass.apply(this, arguments);
>> }
>> 
>> here it already got the problem that TestClass - being a constructor - does 
>> not have .bind() or .apply().
>> 
>> Does someone know how to get this working?
>> 
>> Thank you very much,
>> 
>> Mo
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org 
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] JavaScriptCore subclass native class created with JSClassCreate in javascript code

[Geoffrey Garen]

You’ll need to manually copy Function.prototype.apply to the TestClass 
prototype.

Another option is “Function.prototype.apply.call(TestClass, this, arguments)”.

Geoff

> On Oct 2, 2014, at 8:26 AM, Moritz Moeller  wrote:
> 
> Hi,
> 
> I’ve created a javascript class in native code (i.e. JSClassCreate, 
> JSObjectMakeConstructor etc.) and want to subclass this class in javascript.
> 
> So pretty much:
> 
> JSClassDefinition classDef = kJSClassDefinitionEmpty;
> classDef.className = "TestClass";
> classDef.getProperty = class_getProperty;
> classDef.setProperty = class_setProperty;
> JSClassRef classRef = JSClassCreate(&classDef);
> JSObjectRef constructor = JSObjectMakeConstructor(ctx, gClassRef, 
> class_constructor);
> JSObjectSetProperty(ctx, JSContextGetGlobalObject(ctx), 
> JsString("TestClass"), constructor, 0, NULL);
> 
> class_constructor does:
> return JSObjectMake(ctx, classRef, NULL);
> 
> This works, so I can do
> var test = new TestClass();
> test.field = 1;
> 
> and both class_constructor and class_setProperty is called.
> 
> Now I’m trying to subclass the TestClass:
> function SubClass()
> {
> TestClass.apply(this, arguments);
> }
> 
> here it already got the problem that TestClass - being a constructor - does 
> not have .bind() or .apply().
> 
> Does someone know how to get this working?
> 
> Thank you very much,
> 
> Mo
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Behavior change: is<>(T*) is now doing a null check on the pointer argument

[Chris Dumez]

Hi,

I would like to bring attention to a behavior change I have just landed [1]. 
The is<>(T*) type checking function is now doing a null-check on the pointer 
argument instead of simply asserting that the pointer argument should not be 
null.

Please keep this in mind in your future patches:
- If you know the pointer cannot be null (because a null check was done earlier 
in the function), then call the is<>(T&) overload taking a reference in 
argument to avoid the null check: e.g. “if (is(*node)) …"
- Do not do an explicit null check on the pointer before calling is<>(T*). “if 
(node && is(node))” -> "if (is(T*) which will correctly cast a null 
pointer.
- Having a is<>(T*) overload in addition to is<>(T&) was previously only 
helpful to avoid having to dereference the pointer. Dereferencing is just one 
‘*’ character and doesn’t decrease code readability much IMHO. However, getting 
rid of a lot of explicit null checks does simplify the code quite a bit.

FYI, all Node subclasses should now support is<>() / downcast<>() already. I am 
in the process of porting non-Node classes over as well for consistency 
(WorkerGlobalScope class, File class and Event subclasses were already ported 
for e.g.).
If you try to use is<>() / downcast<>() for a class that doesn’t support it 
yet, you should now get a clear build error (instead of the obscure linking 
error we would get previously).

Kr,
--
Chris Dumez - Apple Inc.
Cupertino, CA

[1]  http://trac.webkit.org/changeset/174225 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] JavaScriptCore subclass native class created with JSClassCreate in javascript code

[Moritz Moeller]

Hi,

I’ve created a javascript class in native code (i.e. JSClassCreate, 
JSObjectMakeConstructor etc.) and want to subclass this class in javascript.

So pretty much:

JSClassDefinition classDef = kJSClassDefinitionEmpty;
classDef.className = "TestClass";
classDef.getProperty = class_getProperty;
classDef.setProperty = class_setProperty;
JSClassRef classRef = JSClassCreate(&classDef);
JSObjectRef constructor = JSObjectMakeConstructor(ctx, gClassRef, 
class_constructor);
JSObjectSetProperty(ctx, JSContextGetGlobalObject(ctx), 
JsString("TestClass"), constructor, 0, NULL);

class_constructor does:
return JSObjectMake(ctx, classRef, NULL);

This works, so I can do
var test = new TestClass();
test.field = 1;

and both class_constructor and class_setProperty is called.

Now I’m trying to subclass the TestClass:
function SubClass()
{
TestClass.apply(this, arguments);
}

here it already got the problem that TestClass - being a constructor - does not 
have .bind() or .apply().

Does someone know how to get this working?

Thank you very much,

Mo___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev