added check for native js objects to __instanceof

[mockey]

Std.is should work with native objects where typeof returns "object" now
added function for getting js [[Class]]
added function for resolving native classes
added handling of native objects to getClass
added null-check to Type.getClassName to avoid error when a native class is used
added resolving of native classes to Type.resolveClass

[mockey]

Where would I add special unit tests for testing this? I see Std.is is tested mainly in TestReflect? Is there a place for special js tests or would add an Issue under /issues?

[Simn]

Now that you have an issue ID it makes sense to add an issue test. I'm trying to write all tests as issue tests from now on because it has several advantages.

[mockey]

OK, for js-specific stuff, like checking DOM-objects, do you add #if js to the Issue then? And is it enough to only run compile-js.hxml?
Or is there a readme for correctly adding unit tests somewhere? :-)

[Simn]

I would just wrap the test class fields in #if js ... #end.

[mockey]

Ok, I'll add some tests.

[mockey]

I added some first tests. Will try to make up some more.
BTW: this __nativeClassName function I added, might also be useful in __string_rec in js.Boot.
It's a pretty common JS technique, as described her e.g.:
http://javascript.info/tutorial/type-detection#class-to-differ-between-native-objects

[hexonaut]

This is great! I was working on this problem for a couple of days, and couldn't come up with a good solution. This method seems to work cross browser.

[ncannasse]

Using "window" / "global" is not good, since it will return false positive, for instance resolveClass("addEventListener"). Also, I'm not a big fan of having getClass doing an extra memory allocation (by calling toString()), since this should significantly slowdown both getClass and instanceOf

[Simn]

Couldn't the check be inverted, i.e. if __class__ is available use that, else go into the dirty target-specific internals.

[mockey]

Type.resolveClass doesn't work anyway, you would need the native class, i.e. HTMLVideoElement instead of js.html.VideoElement. So I would only use __resolveNativeClass in getClass but maybe that's not really needed for native objects...
You can also store a reference to {}.toString, so the same function gets called every time. Don't know if there's an extra memory allocation then. But if [[Class]] is not used in getClass or in __string_rec you can also just drop it.
All in all this is not really needed, I just thought it might be nice to have some support for native objects...
You can also simply add typeof cl == "object" to __instanceof. You just have to exclude Math and JSON there because you get an error with instanceof on these "objects". That's what broke the unit tests on Sam's first commit.

[Simn]

This looks good to me now because all the native handling only happens if __class__ returns null.

[ncannasse]

Just a last nitpick maybe, we could check for instanceof before checking nativeClass ?

[mockey]

You mean in __instanceof? The problem is that there are some classes (namely Math and JSON AFAIK) where typeof returns "object" but you get an error when you check instanceof on them. As I wrote before you could simply use:
else if (typeof cl == "object" && cl != Math && cl != JSON)
here, if you prefer.

[mockey]

Will this be merged eventually?
As said, the current js.Boot breaks on current Safari (desktop and iOS). I just came across that __cast error once more, which reminded me of that pull request...

[ncannasse]

Ok sounds fine, let's merge and hopefully this will not create any issue.

[andyli]

The test case needs to be revised.
Following are failed test results from TravisCI.

IE8:

Test.hx:240: Generated at: 2014-07-13 15:30:24
Test.hx:242: START
Test.hx:224: ABORTED : TypeError: 'HTMLVideoElement' is undefined in unit.issues.Issue2857.testElement
Test.hx:227: STACK : undefinedcbc
Test.hx:187: DONE [4856 tests]
Test.hx:334: SUCCESS: false

IE9:

Test.hx:240: Generated at: 2014-07-13 15:30:24
Test.hx:242: START
Test.hx:224: ABORTED : ReferenceError: 'ArrayBuffer' is undefined in unit.issues.Issue2857.testElement
Test.hx:227: STACK : undefined
Test.hx:187: DONE [4860 tests]
Test.hx:334: SUCCESS: false

[ncannasse]

@mockey any suggestion to replace these ? I'm not sure which classes values are actually defined in IE8

[mockey]

Oh, IE, hmm. Are IE8 and IE9 new? I think TravisCI didn't fail in April.
I'll think about a test that works in IE8 then.

[andyli]

Our Travis setting does not run SauceLabs browser tests for pull request, due to the use of secure env variables for SauceLabs auth. That is a sad limitation.

[Simn]

Could we either fix this or disable the test? It's quite irritating to have a constant fail case like that.

[mockey]

I have no time for a fix atm. So better disable it for now. I will look into it at the weekend.

[Simn]

Alright, thanks for the heads up. I have disabled the test for now.