New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dart2js: Object is using mixed up calling conventions #8942
Comments
This comment was originally written by ngeoffray@google.com It's actually not mixed up and deliberate. In general, methods in Object should use the first argument, because the receiver might be a primitive. Because we know operator== will be in all interceptor classes (the emitter manually adds them), we can have the operator== just use 'this' instead. See builder.dart: buildMethod. But it's fine to use the first argument for operator==. |
You will agree the naming is inconsistent with use? The emitter can't manually add for all 500 DOM types - too much code. |
This comment was originally written by ngeoffray@google.com That sounds good to me. Object has always been in this akward state with the interceptors v1, and interceptors with new calling conventions. I haven't done a great job on making it consistent, but that's mostly because I knew the DOM types would come in the game :), and would most probably bring up their own requirements. |
Added this to the Later milestone. |
Added TriageForM5 label. |
Removed TriageForM5 label. |
Removed this from the Later milestone. |
Removed Oldschool-Milestone-Later label. |
All intercepted classes extend Interceptor. |
There are four calling 'conventions':
1. direct: receiver.foo(arg)
And three variations of passing an explicit receiver:
2. intercepted: interceptor.foo(receiver, arg)
The interceptor and receiver are (potentially) different objects; the receiver is passed as the first parameter and its receiver is passed as the 'this' parameter.
3. interceptor: receiver.foo(receiver, arg)
Used in a context where all possible receivers are self-intercepting, but the method may be reached by an interceptor or a self-intercepting class. Example: a method from a mixin placed on a plain class and an intercepted class will need a correct explicit receiver, even if we know the receiver is a plain class.
4. ignored-explicit-receiver: receiver.foo(0, arg)
Smaller call site used when the set of 'foo' implementations are all for self-intercepting classes and access the receiver via 'this'.
3 is a current optimization of #2 when no genuine interceptors are possible.
4 is a future optimization of #3.
By convention, ignored-receiver methods rename the 'receiver' first argument to '_' and don't use it.
Object seems very confused:
$$.Object = {"": ";",
//// $eq names the receiver but ignores it!!!
$eq: function(receiver, other) {
return this === other;
},
//// get$hashCode has an ignored-receiver name, but uses it!!!
get$hashCode: function() {
return $.Primitives_objectHashCode();
},
toString$0: function() {
return "Instance of '" + $.S($.Primitives_objectTypeName()) + "'";
}
};
We need to decide if Object can subclassed by an interceptor class or by a regular class.
If it is both, then we can't use convention #4 for methods on Object, and we need to fix $eq and whatever is causing the incorrect naming of the 'receiver' parameter.
The text was updated successfully, but these errors were encountered: