Change signature of noSuchMethod to take an InvocationMirror.

Change signature of noSuchMethod to take an InvocationMirror.

Requires VM and dart2js/dart2dart changes to work.

Committed: https://code.google.com/p/dart/source/detail?r=14198

Committed: https://code.google.com/p/dart/source/detail?r=14254

Committed: https://code.google.com/p/dart/source/detail?r=14324

[Lasse Reichstein Nielsen, 2012-10-23 12:47:40]

Contacting VM/dart2* for compatibility CLs.

[Anton Muhin, 2012-10-23 12:49:12]

dart:html changes lgtm

[floitsch, 2012-10-23 13:04:34]

LGTM.
added Gram (because of change to pkg/unittest).

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart
File lib/core/errors.dart (right):

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode68
lib/core/errors.dart:68: final Map<String,Dynamic> _namedArguments;
String, Dynamic (space)

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode87
lib/core/errors.dart:87: Map<String,Dynamic> this._namedArguments,
no need to type. the type comes from the field.

https://codereview.chromium.org/11231074/diff/1/pkg/unittest/mock.dart
File pkg/unittest/mock.dart (right):

https://codereview.chromium.org/11231074/diff/1/pkg/unittest/mock.dart#newcod...
pkg/unittest/mock.dart:1271: * This is the handler for method calls. We loo
through the list
loop

[Ivan Posva, 2012-10-24 22:17:20]

+regis

I am failing to see the actual implementation of the InvocationMirror class in
this CL. Is there a CL that this is dependent on?

Thanks,
-Ivan

[regis, 2012-10-25 02:27:56]

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart
File lib/core/errors.dart (right):

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode68
lib/core/errors.dart:68: final Map<String,Dynamic> _namedArguments;
On 2012/10/23 13:04:35, floitsch wrote:
> String, Dynamic (space)

dynamic is now lower case.

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode74
lib/core/errors.dart:74: * The first parameter is the receiver of the method
call.
What is the value of the first parameter when a NoSuchMethodError is thrown
after an invoked static function is not found? Is it null?

What about the case when a constructor is not found? Do you pass the allocated
but uninitialized object as 'this'?

Related question, can you forward a constructor call via noSuchMethod using the
InvocationMirror? In other words, do you keep the implicit arguments? 

Same questions for factories.

Invoking a method on null results in a NullPointerException, a subclass of
NoSuchMethodError. Do you declare NullPointerException elsewhere?

For a NoSuchMethodError resulting from a non-closure object being called, I
suppose that the value of functionName will be "call" and the value of 'this'
will be the non-closure object. Should this be documented here?

For a NoSuchMethodError resulting from a closure object being called with
incompatible arguments, I suppose that the value of functionName will be "call"
and the value of 'this' will be the closure object. The arguments will be set
accordingly to the explicit arguments, but what about the hidden context? This
question relates more to the noSuchMethod itself. In other words, can you
forward a closure call via noSuchMethod?

[Lasse Reichstein Nielsen, 2012-10-25 06:17:35]

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart
File lib/core/errors.dart (right):

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode68
lib/core/errors.dart:68: final Map<String,Dynamic> _namedArguments;
On 2012/10/23 13:04:35, floitsch wrote:
> String, Dynamic (space)

I actually have come to prefer it without spaces. I'll argue at length about
that offline :)

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode74
lib/core/errors.dart:74: * The first parameter is the receiver of the method
call.
On 2012/10/25 02:27:56, regis wrote:
> What is the value of the first parameter when a NoSuchMethodError is thrown
> after an invoked static function is not found? Is it null?

Goooood question. Spec is silent on this.
For consistency, I'd suggest treating the global scope (for top-level
functions), or the class (for static methods) as a pseudo-object, and use the
name that was attempted called as the name in the NoSuchMethodError.
For the 'this' value, I'd use null for the top-level 'object' and the Type of
the class as the class 'object'. The need for the Type object is statically
deducible, so it shouldn't force dart2js to include runtime-types unnecessarily.

> 
> What about the case when a constructor is not found? Do you pass the allocated
> but uninitialized object as 'this'?

If the constructor is not found, there should be no uninitialized object (you
don't know if the missing constructor is generative or a factory). Even if there
was, an uninitialized object should never be revealed.

> 
> Related question, can you forward a constructor call via noSuchMethod using
the
> InvocationMirror? In other words, do you keep the implicit arguments? 


You can't get an InvocationMirror for static calls or constructor calls, since
there is no object with a noSuchMethod method to catch it. They always throw.
It's deliberate that the NoSuchMethodError does not contain an InvocationMirror
- you only need an InvocationMirror for user-defined noSuchMethod methods.

> Same questions for factories.

Same answer, they are essentially static.

> 
> Invoking a method on null results in a NullPointerException, a subclass of
> NoSuchMethodError. Do you declare NullPointerException elsewhere?

I suggest removing/stop using NullPointerException and just throwing a
NoSuchMethodError for calls on null as well. The spec allows it, and it's
simpler than worrying about null.
NullPointerException is defined in the core library, but isn't currently a
subclass of NoSuchMethodError (which the spec requires).

 
> For a NoSuchMethodError resulting from a non-closure object being called, I
> suppose that the value of functionName will be "call" and the value of 'this'
> will be the non-closure object. Should this be documented here?

It could be, for documentation. It's a consequence of how the spec is written
that foo() is equivalent to foo.call().

> 
> For a NoSuchMethodError resulting from a closure object being called with
> incompatible arguments, I suppose that the value of functionName will be
"call"
> and the value of 'this' will be the closure object. The arguments will be set
> accordingly to the explicit arguments, but what about the hidden context? This
> question relates more to the noSuchMethod itself. In other words, can you
> forward a closure call via noSuchMethod?

Which hidden context?
The InvocationMirror does not contain the 'this' value of the call, just the
name and argument values, so there is no context in there at all. 
The noSuchMethod has a this that is the object for method calls and the closure
for closure calls (where the method is implicitly "call" on the closure).

It is interesting that for obj of class X{bar(int x){} noSuchMethod(x){}}:
 obj.bar(2,3)  will trigger obj's noSuchMethod with a mirri with name 'bar' and
positional arguments [2,3], but
 (obj.bar)(2,3)  will trigger obj.bar (the closure)'s noSuchMethod inherited
from Object and throw a NoSuchMethodError with name 'call'. It's really same as
obj.bar.call(2,3).

I'll forward that to Gilad and see if it's acceptable :)

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode87
lib/core/errors.dart:87: Map<String,Dynamic> this._namedArguments,
True. And dynamic is lower-case now.

https://codereview.chromium.org/11231074/diff/1/pkg/unittest/mock.dart
File pkg/unittest/mock.dart (right):

https://codereview.chromium.org/11231074/diff/1/pkg/unittest/mock.dart#newcod...
pkg/unittest/mock.dart:1271: * This is the handler for method calls. We loo
through the list
Good catch.

[Lasse Reichstein Nielsen, 2012-10-25 08:00:53]

> It is interesting that for obj of class X{bar(int x){} noSuchMethod(x){}}:
>  obj.bar(2,3)  will trigger obj's noSuchMethod with a mirri with name 'bar'
and
> positional arguments [2,3], but
>  (obj.bar)(2,3)  will trigger obj.bar (the closure)'s noSuchMethod inherited
> from Object and throw a NoSuchMethodError with name 'call'. It's really same
as
> obj.bar.call(2,3).


I take that back, obj.bar() and (obj.bar)() work the same.

[Lasse Reichstein Nielsen, 2012-10-25 09:04:39]

And as a side note, the behavior on static calls is not affected by this change,
it's only the behavior of calling noSuchMethod on an instance that is affected.
Changing static calls to throw NoSuchMethodError is a separate issue.

[regis, 2012-10-25 17:47:16]

LGTM

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart
File lib/core/errors.dart (right):

https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode74
lib/core/errors.dart:74: * The first parameter is the receiver of the method
call.
On 2012/10/25 06:17:35, Lasse Reichstein Nielsen wrote:
> On 2012/10/25 02:27:56, regis wrote:
> > What is the value of the first parameter when a NoSuchMethodError is thrown
> > after an invoked static function is not found? Is it null?
> 
> Goooood question. Spec is silent on this.
> For consistency, I'd suggest treating the global scope (for top-level
> functions), or the class (for static methods) as a pseudo-object, and use the
> name that was attempted called as the name in the NoSuchMethodError.
> For the 'this' value, I'd use null for the top-level 'object' and the Type of
> the class as the class 'object'. The need for the Type object is statically
> deducible, so it shouldn't force dart2js to include runtime-types
unnecessarily.
> 
That sounds reasonable. By 'this' value, you probably mean the first element of
the _arguments list and not _receiver? And by 'object', you actually mean
_receiver? Otherwise I do not understand your reply. Sorry, my question was not
very clear either.

I do not see the need to insert a null as 'this' as the first element of
_arguments. _arguments should match what was passed to the static call.

So, to be clear, in the case of a static call error, _receiver should be the
type of the class owning the static function, or null if the static function is
top level or not resolved. The _arguments should not be tempered with. 

The comment on line 74 could be made clearer:
The first parameter is the receiver of the method call or the first argument of
the static call.

> > 
> > What about the case when a constructor is not found? Do you pass the
allocated
> > but uninitialized object as 'this'?
> 
> If the constructor is not found, there should be no uninitialized object (you
> don't know if the missing constructor is generative or a factory). Even if
there
> was, an uninitialized object should never be revealed.
> 
Agreed. In other words, implicit arguments should be removed from _arguments.

> > 
> > Related question, can you forward a constructor call via noSuchMethod using
> the
> > InvocationMirror? In other words, do you keep the implicit arguments? 
> 
> 
> You can't get an InvocationMirror for static calls or constructor calls, since
> there is no object with a noSuchMethod method to catch it. They always throw.
> It's deliberate that the NoSuchMethodError does not contain an
InvocationMirror
> - you only need an InvocationMirror for user-defined noSuchMethod methods.
> 
> > Same questions for factories.
> 
> Same answer, they are essentially static.
> 
> > 
> > Invoking a method on null results in a NullPointerException, a subclass of
> > NoSuchMethodError. Do you declare NullPointerException elsewhere?
> 
> I suggest removing/stop using NullPointerException and just throwing a
> NoSuchMethodError for calls on null as well. The spec allows it, and it's
> simpler than worrying about null.
> NullPointerException is defined in the core library, but isn't currently a
> subclass of NoSuchMethodError (which the spec requires).
>
It would be awesome to remove NullPointerException. Hopefully Gilad has no issue
with it.

>  
> > For a NoSuchMethodError resulting from a non-closure object being called, I
> > suppose that the value of functionName will be "call" and the value of
'this'
> > will be the non-closure object. Should this be documented here?
> 
> It could be, for documentation. It's a consequence of how the spec is written
> that foo() is equivalent to foo.call().
> 
> > 
> > For a NoSuchMethodError resulting from a closure object being called with
> > incompatible arguments, I suppose that the value of functionName will be
> "call"
> > and the value of 'this' will be the closure object. The arguments will be
set
> > accordingly to the explicit arguments, but what about the hidden context?
This
> > question relates more to the noSuchMethod itself. In other words, can you
> > forward a closure call via noSuchMethod?
> 
> Which hidden context?

The context is part of the closure object itself. That answers my dumb question.

Thinking about it some more, I realize that it is not possible to forward a
closure call via noSuchMethod, since it is not possible for the user to add a
noSuchMethod to a closure class, which is generated by the compiler. Never mind.


> The InvocationMirror does not contain the 'this' value of the call, just the
> name and argument values, so there is no context in there at all. 
> The noSuchMethod has a this that is the object for method calls and the
closure
> for closure calls (where the method is implicitly "call" on the closure).
> 
> It is interesting that for obj of class X{bar(int x){} noSuchMethod(x){}}:
>  obj.bar(2,3)  will trigger obj's noSuchMethod with a mirri with name 'bar'
and
> positional arguments [2,3], but
>  (obj.bar)(2,3)  will trigger obj.bar (the closure)'s noSuchMethod inherited
> from Object and throw a NoSuchMethodError with name 'call'. It's really same
as
> obj.bar.call(2,3).
> 
> I'll forward that to Gilad and see if it's acceptable :)

That makes sense.

[regis, 2012-10-25 20:37:39]

On 2012/10/25 08:00:53, Lasse Reichstein Nielsen wrote:
> > It is interesting that for obj of class X{bar(int x){} noSuchMethod(x){}}:
> >  obj.bar(2,3)  will trigger obj's noSuchMethod with a mirri with name 'bar'
> and
> > positional arguments [2,3], but
> >  (obj.bar)(2,3)  will trigger obj.bar (the closure)'s noSuchMethod inherited
> > from Object and throw a NoSuchMethodError with name 'call'. It's really same
> as
> > obj.bar.call(2,3).
> 
> 
> I take that back, obj.bar() and (obj.bar)() work the same.

You mean, do *not* work the same, right?

With obj.bar(), we end up calling X's noSuchMethod() with obj as the receiver
and "bar" as the function name. The receiver and the function name are fields of
the invocation mirror passed to noSuchMethod(). However, with (obj.bar)(), we
end up calling Object's noSuchMethod which throws a NoSuchMethodError with the
closure obj.bar as the receiver and "call" as the function name. The receiver
and the function name are fields of NoSuchMethodError.

Not quite the same.

[Ivan Posva, 2012-10-26 02:34:26]

May I reiterate my question from earlier:

Where is the InvocationMirror implementation class?

Thanks,
-Ivan

https://chromiumcodereview.appspot.com/11231074/diff/1/lib/compiler/implement...
File lib/compiler/implementation/lib/core_patch.dart (right):

https://chromiumcodereview.appspot.com/11231074/diff/1/lib/compiler/implement...
lib/compiler/implementation/lib/core_patch.dart:22: patch Dynamic
noSuchMethod(InvocationMirror invocation) {
dynamic

[Lasse Reichstein Nielsen, 2012-10-26 11:33:18]

The implementation is in runtime/lib/invocation_mirror_patch.dart
It is already committed, and isn't part of this CL.

[regis, 2012-10-26 23:27:08]

https://codereview.chromium.org/11231074/diff/11001/lib/core/errors.dart
File lib/core/errors.dart (right):

https://codereview.chromium.org/11231074/diff/11001/lib/core/errors.dart#newc...
lib/core/errors.dart:78: final Map<String, dynamic> _namedArguments;
Why not an InvocationMirror, instead of _functionName, _arguments, and
_namedArguments?

https://codereview.chromium.org/11231074/diff/11001/lib/core/errors.dart#newc...
lib/core/errors.dart:97: this._namedArguments,
We could pass the receiver and invocation mirror instead of separate fields.

[Lasse Reichstein Nielsen, 2012-10-27 21:13:47]

On 2012/10/25 20:37:39, regis wrote:

> You mean, do *not* work the same, right?

No, I mean that they do work the same, because the spec handles
 expression(arg)
specially if "expression" is a property access, so (foo.bar)(arg) is defined to
be exactly the same as foo.bar(arg). Pure syntax trickery.
If you do: var x = foo.bar;x(arg) then it's hitting the closure object's
noSuchMethod inherited from Object.

> With obj.bar(), we end up calling X's noSuchMethod() with obj as the receiver
> and "bar" as the function name. The receiver and the function name are fields
of
> the invocation mirror passed to noSuchMethod(). However, with (obj.bar)(), we
> end up calling Object's noSuchMethod which throws a NoSuchMethodError with the
> closure obj.bar as the receiver and "call" as the function name. The receiver
> and the function name are fields of NoSuchMethodError.

Not with that particular syntax. From the section "Function expression
invocation": "If e_f is a property access expression, then i is treated as an
ordinary method invocation."

[Lasse Reichstein Nielsen, 2012-10-27 21:52:38]

On 2012/10/25 17:47:16, regis wrote:
> LGTM
> 
> https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart
> File lib/core/errors.dart (right):
> 
> https://codereview.chromium.org/11231074/diff/1/lib/core/errors.dart#newcode74
> lib/core/errors.dart:74: * The first parameter is the receiver of the method
> call.
> On 2012/10/25 06:17:35, Lasse Reichstein Nielsen wrote:
> > On 2012/10/25 02:27:56, regis wrote:
> > > What is the value of the first parameter when a NoSuchMethodError is
thrown
> > > after an invoked static function is not found? Is it null?
> > 
> > Goooood question. Spec is silent on this.
> > For consistency, I'd suggest treating the global scope (for top-level
> > functions), or the class (for static methods) as a pseudo-object, and use
the
> > name that was attempted called as the name in the NoSuchMethodError.
> > For the 'this' value, I'd use null for the top-level 'object' and the Type
of
> > the class as the class 'object'. The need for the Type object is statically
> > deducible, so it shouldn't force dart2js to include runtime-types
> unnecessarily.
> > 
> That sounds reasonable. By 'this' value, you probably mean the first element
of
> the _arguments list and not _receiver?

I mean the receiver of the call in both cases, the first argument of the
NoSuchMethodError constructor. There is no receiver for a top-level static call,
so I thought "null" would be a reasonable replacement. I'm not so sure any more,
since doing: null.flumcake() can also throw a NoSuchMethodError (or the subclass
NullPointerException) which should then have the null value as a receiver. We
should maybe have a boolean to say if the call is static instead.

All this is unspecified - the spec just says to throw a NoSuchMethodError, not
anything about what it might contain.
From a security standpoint, precomputing the error message and just storing a
string might even be better - less danger of accidentally revealing internal
objects.

> And by 'object', you actually mean
> _receiver? Otherwise I do not understand your reply. Sorry, my question was
not
> very clear either.
> 
> I do not see the need to insert a null as 'this' as the first element of
> _arguments. _arguments should match what was passed to the static call.
> 
> So, to be clear, in the case of a static call error, _receiver should be the
> type of the class owning the static function, or null if the static function
is
> top level or not resolved. The _arguments should not be tempered with. 

Agree (but a little worried about using null as receiver for top-level calls
since it can also be a valid receiver object by itself).

> The comment on line 74 could be made clearer:
> The first parameter is the receiver of the method call or the first argument
of
> the static call.

It's the receiver. Let's see if I can make it clearer.

 
> > > 
> > > What about the case when a constructor is not found? Do you pass the
> allocated
> > > but uninitialized object as 'this'?
> > 
> > If the constructor is not found, there should be no uninitialized object
(you
> > don't know if the missing constructor is generative or a factory). Even if
> there
> > was, an uninitialized object should never be revealed.
> > 
> Agreed. In other words, implicit arguments should be removed from _arguments.
> 
> > > 
> > > Related question, can you forward a constructor call via noSuchMethod
using
> > the
> > > InvocationMirror? In other words, do you keep the implicit arguments? 
> > 
> > 
> > You can't get an InvocationMirror for static calls or constructor calls,
since
> > there is no object with a noSuchMethod method to catch it. They always
throw.
> > It's deliberate that the NoSuchMethodError does not contain an
> InvocationMirror
> > - you only need an InvocationMirror for user-defined noSuchMethod methods.
> > 
> > > Same questions for factories.
> > 
> > Same answer, they are essentially static.
> > 
> > > 
> > > Invoking a method on null results in a NullPointerException, a subclass of
> > > NoSuchMethodError. Do you declare NullPointerException elsewhere?
> > 
> > I suggest removing/stop using NullPointerException and just throwing a
> > NoSuchMethodError for calls on null as well. The spec allows it, and it's
> > simpler than worrying about null.
> > NullPointerException is defined in the core library, but isn't currently a
> > subclass of NoSuchMethodError (which the spec requires).
> >
> It would be awesome to remove NullPointerException. Hopefully Gilad has no
issue
> with it.
> 
> >  
> > > For a NoSuchMethodError resulting from a non-closure object being called,
I
> > > suppose that the value of functionName will be "call" and the value of
> 'this'
> > > will be the non-closure object. Should this be documented here?
> > 
> > It could be, for documentation. It's a consequence of how the spec is
written
> > that foo() is equivalent to foo.call().
> > 
> > > 
> > > For a NoSuchMethodError resulting from a closure object being called with
> > > incompatible arguments, I suppose that the value of functionName will be
> > "call"
> > > and the value of 'this' will be the closure object. The arguments will be
> set
> > > accordingly to the explicit arguments, but what about the hidden context?
> This
> > > question relates more to the noSuchMethod itself. In other words, can you
> > > forward a closure call via noSuchMethod?
> > 
> > Which hidden context?
> 
> The context is part of the closure object itself. That answers my dumb
question.
> 
> Thinking about it some more, I realize that it is not possible to forward a
> closure call via noSuchMethod, since it is not possible for the user to add a
> noSuchMethod to a closure class, which is generated by the compiler. Never
mind.
> 
> 
> > The InvocationMirror does not contain the 'this' value of the call, just the
> > name and argument values, so there is no context in there at all. 
> > The noSuchMethod has a this that is the object for method calls and the
> closure
> > for closure calls (where the method is implicitly "call" on the closure).
> > 
> > It is interesting that for obj of class X{bar(int x){} noSuchMethod(x){}}:
> >  obj.bar(2,3)  will trigger obj's noSuchMethod with a mirri with name 'bar'
> and
> > positional arguments [2,3], but
> >  (obj.bar)(2,3)  will trigger obj.bar (the closure)'s noSuchMethod inherited
> > from Object and throw a NoSuchMethodError with name 'call'. It's really same
> as
> > obj.bar.call(2,3).
> > 
> > I'll forward that to Gilad and see if it's acceptable :)
> 
> That makes sense.

[Lasse Reichstein Nielsen, 2012-10-27 21:52:45]

https://codereview.chromium.org/11231074/diff/11001/lib/core/errors.dart
File lib/core/errors.dart (right):

https://codereview.chromium.org/11231074/diff/11001/lib/core/errors.dart#newc...
lib/core/errors.dart:78: final Map<String, dynamic> _namedArguments;
Two reasons.
The first is that you might want to optimize away calls to Object.noSuchMethod
and just throw a NoSuchMethodError directly, without ever creating an
InvocationMirror.
I just didn't see a reason to make a dependency between the two classes when it
could be avoided.
Second, we need to throw NoSuchMethodError on static calls as well, where there
is no need for an InvocationMirror at all.
And third: plain paranoid defensive programming - I don't want the invokeOn
function to get around unnecessarily.

[Lasse Reichstein Nielsen, 2012-10-29 11:01:45]

Johnni, please take a look at the dart2js changes.

[Johnni Winther, 2012-10-29 12:05:55]

LGTM with comments.

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
File lib/compiler/implementation/lib/js_helper.dart (right):

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
lib/compiler/implementation/lib/js_helper.dart:377: if (_namedArgumentNames !=
null && _namedArgumentNames.length > 0) {
Do we need to do this at all when [_namedIndices] is only used in the
[namedArguments] getter ?

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
File lib/compiler/implementation/ssa/codegen.dart (right):

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
lib/compiler/implementation/ssa/codegen.dart:1518: // If [noSuchMethod] has been
overridden and [InvocationMirror.invokeOn]
Change to 'If [JSInvocationMirror.invokeOn] has been called ...'

[Johnni Winther, 2012-10-29 12:19:01]

On 2012/10/29 12:05:55, Johnni Winther wrote:
> LGTM with comments.
> 
>
https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
> File lib/compiler/implementation/lib/js_helper.dart (right):
> 
>
https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
> lib/compiler/implementation/lib/js_helper.dart:377: if (_namedArgumentNames !=
> null && _namedArgumentNames.length > 0) {
> Do we need to do this at all when [_namedIndices] is only used in the
> [namedArguments] getter ?
> 
>
https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
> File lib/compiler/implementation/ssa/codegen.dart (right):
> 
>
https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
> lib/compiler/implementation/ssa/codegen.dart:1518: // If [noSuchMethod] has
been
> overridden and [InvocationMirror.invokeOn]
> Change to 'If [JSInvocationMirror.invokeOn] has been called ...'

See also ahe's comments in https://codereview.chromium.org/11264005/

[Lasse Reichstein Nielsen, 2012-10-30 10:03:31]

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
File lib/compiler/implementation/lib/js_helper.dart (right):

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
lib/compiler/implementation/lib/js_helper.dart:377: if (_namedArgumentNames !=
null && _namedArgumentNames.length > 0) {
Hmm, we could probably do it at that point instead. I'll try a rewrite.

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
File lib/compiler/implementation/ssa/codegen.dart (right):

https://codereview.chromium.org/11231074/diff/20002/lib/compiler/implementati...
lib/compiler/implementation/ssa/codegen.dart:1518: // If [noSuchMethod] has been
overridden and [InvocationMirror.invokeOn]
On 2012/10/29 12:05:55, Johnni Winther wrote:
> Change to 'If [JSInvocationMirror.invokeOn] has been called ...'

Done.