Skip to content
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

Jump to bottom

Would be nice if Dart_Invoke behaved consistently for Class, Library and Instance objects. #11870

Closed
a-siva opened this issue Jul 17, 2013 · 8 comments
Closed

Would be nice if Dart_Invoke behaved consistently for Class, Library and Instance objects. #11870

a-siva opened this issue Jul 17, 2013 · 8 comments
Assignees
@a-siva
Labels
type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@a-siva
Copy link
Contributor

a-siva commented Jul 17, 2013

Comment snippet from Jacob:

For classes, I can just call
Dart_Invoke with the prefix "get:" added to get a closure to a member, invoke a
getter, or get a field.
This is very convenient and it would be nice if I could do the same with
Libraries but currently I cannot.
@a-siva
Copy link
Contributor Author

a-siva commented Jul 17, 2013

Jacob by "For classes" do you mean Instance objects?
I looked at the code for Dart_Invoke and it behaves the same for Library and Class objects but it does have the added functionality of recognizing getters when an
Instance object is passed in.

@a-siva
Copy link
Contributor Author

a-siva commented Jul 17, 2013

The Library object version should also accept names with a prefix.
For example: Dart_Invoke(someLibraryHandle, "someLibraryPrefix.someMemberName");

This should probably be allowed consistently in all functions that provided a lookup
mechanism for Library objects.

@jacob314
Copy link
Member

Correct, I mean instances objects not Class or Type objects.

@a-siva
Copy link
Contributor Author

a-siva commented Sep 13, 2013

Added Dartium-Debugger label.

@a-siva
Copy link
Contributor Author

a-siva commented Sep 18, 2013

Added this to the Later milestone.

@rmacnak-google
Copy link
Contributor

The same thing happens to the mirrors. This is because the implicit closurization for instance methods is handled by Resolver::ResolveDynamic* but for static/top-level methods it is handled in the parser and flow graph compiler.

This is implemented in the mirrors in a pending CL, and we could do the same thing for the embedding API. https://chromiumcodereview.appspot.com/23441073/

@kasperl
Copy link

kasperl commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

@kasperl
Copy link

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@a-siva a-siva self-assigned this Aug 4, 2014
@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed priority-unassigned labels Feb 29, 2016
dart-bot pushed a commit that referenced this issue Aug 9, 2018
@rmacnak-google
[vm] Add a service method for 'invoke' as the dual to 'eval'.
7b9fb89 
Refactor the implementation of 'invoke' for sharing between the embedding API, mirrors, and the VM service. The fixes various issues in the embedding API:
 - Dart_Invoke, Dart_GetField and Dart_SetField now generate the same NoSuchMethodErrors as dart:mirrors and ordinary Dart code.
 - Dart_GetField and Dart_SetField now accept a null receiver.
 - Dart_GetField now handles closurization.
 - Dart_Invoke now handles calls through function-typed getters.
In mirrors, it also changes:
 - LibraryMirror.invoke/getField/setField now see members in the export namespace, not just local declarations. I.e., invocation with a LibraryMirror behaves the same ways as invocation against a library prefix in ordinary Dart code.

Bug: #11870
Bug: #13643
Bug: #29893
Bug: #33417
Bug: #34006
Change-Id: I913e8eef16943a3e86eda55c8d122819e41ad7cc
Reviewed-on: https://dart-review.googlesource.com/67302
Reviewed-by: Siva Annamalai <asiva@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@a-siva a-siva

Labels
type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@kevmoo @matanlurey @jacob314 @kasperl @rmacnak-google @a-siva