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

Be able to look up classes by name using mirrors #5897

Closed
alan-knight opened this issue Oct 15, 2012 · 10 comments
Closed

Be able to look up classes by name using mirrors #5897

alan-knight opened this issue Oct 15, 2012 · 10 comments
Labels
area-library closed-obsolete Closed as the reported issue is no longer relevant library-mirrors P2 A bug or feature request we're likely to work on type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@alan-knight
Copy link
Contributor

With the current mirrors API there isn't a mechanism to look up classes by name in the same scope that they would be visible if typed directly in the program. You can get a mirror for a particular library and find the classes that it declares, but imports aren't visible. Even looking up the other libraries, you don't know if the names are visible at all, or if they have been prefixed. The same applies for any other sort of declaration as well. We need to have either visibility of import information (which would need to include prefixing, re-export, show/hide) or better, the ability to look up a name in a particular scope. The most obvious is static library scope, but this probably generalizes to debugging type APIs and resolving a name that might be a variable on the stack. While those might be separate APIs, it's probably worth thinking about consistency between them.

@alan-knight
Copy link
Contributor Author

I just noticed ClosureMirror.findInContext, which seems like it might be able to do this, although it requires you to obtain a context first. Reflecting on a closure does appear to yield an implementation of ClosureMirror, although the class is marked abstract. But the function also throws not yet implemented, so it's hard to know if it would work for this purpose.

@dgrove
Copy link
Contributor

dgrove commented Oct 16, 2012

cc @gbracha.
Added Area-Analyzer, Triaged labels.

@dgrove
Copy link
Contributor

dgrove commented Oct 16, 2012

Removed Area-Analyzer label.
Added Area-Library label.

@alan-knight
Copy link
Contributor Author

Added Library-Mirrors label.

@nex3
Copy link
Member

nex3 commented Aug 14, 2013

Even if ClosureMirror worked, it would be useful to have an import/export-aware means for looking up a name.

@gbracha
Copy link
Contributor

gbracha commented Aug 24, 2013

It's almost there. Stay tuned.


Set owner to mlippautz@google.com.
Added Accepted label.

@DartBot
Copy link

DartBot commented Sep 27, 2013

This comment was originally written by mlippautz@google.com


Landed in r27982.


Added Fixed label.

@nex3
Copy link
Member

nex3 commented Oct 1, 2013

[ClosureMirror.findInContext] doesn't address the issue described in the bug description. Alan asked for "a mechanism to look up classes by name", but [ClosureMirror.findInContext] only returns InstanceMirrors.

I've modified the bug description to clarify this.


Removed the owner.
Added Triaged label.
Changed the title to: "Be able to look up classes by name using mirrors".

@gbracha
Copy link
Contributor

gbracha commented Oct 1, 2013

Clearly, something more convenient would be nice. The fact remains that findInContext gives a workaround. You can find a name X in scope via reflect(()=>X).findInContext(#X). It is true that you'll get an instance mirror for the Type object, not a ClassMirror. But reflectClass(reflect(()=>X).findInContext(#X).reflectee) should get you there.

In any event, this all you'll have in 1.0.


Set owner to @gbracha.
Added Accepted label.

@nex3
Copy link
Member

nex3 commented Oct 1, 2013

Gilad: that doesn't seem to work. When I run the following code, it prints "null":

    print(reflect(() => String).findInContext(const Symbol('String')));

Even if it worked, this pattern would require that the author know the name of the type when writing the code; it wouldn't provide any benefit over using e.g. "reflect(String)".

@kevmoo kevmoo added P2 A bug or feature request we're likely to work on type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed accepted labels Feb 29, 2016
@lrhn lrhn added the core-m label Aug 11, 2017
@floitschG floitschG removed the core-m label Aug 31, 2017
@matanlurey matanlurey added the closed-obsolete Closed as the reported issue is no longer relevant label Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-library closed-obsolete Closed as the reported issue is no longer relevant library-mirrors P2 A bug or feature request we're likely to work on type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

9 participants