Skip type checks on native JavaScriptObjects

Repurposed this CL: Fix cast error in test

Introduced a private-ish JSObject type.

R=jmesserly@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/4ea129bcaf8a3c19e7f0c964b5fce9dccc3e6dda

[vsm, 2015-08-19 20:05:00]

vsm@google.com changed reviewers:
+ jmesserly@google.com

[Jennifer Messerly, 2015-08-19 20:09:50]

I'm confused. Why would a JS function fail a Dart type test? You shouldn't need
to add a dummy parameter to a callback in JS. Something seems a bit off here...

[vsm, 2015-08-19 20:20:32]

vsm@google.com changed reviewers:
+ leafp@google.com

[vsm, 2015-08-19 20:23:04]

On 2015/08/19 20:09:50, John Messerly wrote:
> I'm confused. Why would a JS function fail a Dart type test? You shouldn't
need
> to add a dummy parameter to a callback in JS. Something seems a bit off
here...

It's getting passed into Dart code.  On a dynamic call, Dart looks for function
type metadata, and if it doesn't find that, assigns it a type matching its
arity.

The alternative is to not do a type check at all in that case.  I just tried
Angular, and the only time we hit that path (where we fall back on arity) is via
dart:js calls - a good sign.  :-)

What do you guys think?

[Jennifer Messerly, 2015-08-19 20:53:05]

On 2015/08/19 20:23:04, vsm wrote:
> On 2015/08/19 20:09:50, John Messerly wrote:
> > I'm confused. Why would a JS function fail a Dart type test? You shouldn't
> need
> > to add a dummy parameter to a callback in JS. Something seems a bit off
> here...
> 
> It's getting passed into Dart code.  On a dynamic call, Dart looks for
function
> type metadata, and if it doesn't find that, assigns it a type matching its
> arity.
> 
> The alternative is to not do a type check at all in that case.  I just tried
> Angular, and the only time we hit that path (where we fall back on arity) is
via
> dart:js calls - a good sign.  :-)
> 
> What do you guys think?

Yeah, I'd prefer to skip the check for a JS function ... the arity isn't really
reliable for them.

[Leaf, 2015-08-19 21:49:01]

On 2015/08/19 20:53:05, John Messerly wrote:
> On 2015/08/19 20:23:04, vsm wrote:
> > On 2015/08/19 20:09:50, John Messerly wrote:
> > > I'm confused. Why would a JS function fail a Dart type test? You shouldn't
> > need
> > > to add a dummy parameter to a callback in JS. Something seems a bit off
> > here...
> > 
> > It's getting passed into Dart code.  On a dynamic call, Dart looks for
> function
> > type metadata, and if it doesn't find that, assigns it a type matching its
> > arity.
> > 
> > The alternative is to not do a type check at all in that case.  I just tried
> > Angular, and the only time we hit that path (where we fall back on arity) is
> via
> > dart:js calls - a good sign.  :-)
> > 
> > What do you guys think?
> 
> Yeah, I'd prefer to skip the check for a JS function ... the arity isn't
really
> reliable for them.

+1.  My sense is that we probably will want to allow JS things to masquerade as
any dart object to make interop as seamless as possible.  Otherwise it gets
difficult to allow Dart artifacts to be consumed by JS.

[vsm, 2015-08-19 23:33:11]

PTAL

[Jennifer Messerly, 2015-08-19 23:37:16]

lgtm

[vsm, 2015-08-20 13:32:01]

Committed patchset #2 (id:20001) manually as
4ea129bcaf8a3c19e7f0c964b5fce9dccc3e6dda (presubmit successful).