Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(251)

Side by Side Diff: mirrors/corelib_mirrors.dart

Issue 9007019: Revised Mirrors proposal/take 3. (Closed) Base URL: http://dart.googlecode.com/svn/experimental/
Patch Set: Created 9 years ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch | Annotate | Revision Log
« no previous file with comments | « no previous file | mirrors/debug.dart » ('j') | mirrors/debug.dart » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
(Empty)
1 #library("corelib_mirrors");
2 #import("introspection.dart");
3
4 /** This class should be part of the core library.
5 It is used both in the Function interface and the InvocationMirror interface * /
6 class ArgumentDescriptor {
7 final List<Dynamic> positionalArguments;
ahe 2012/01/02 16:21:14 Nit: I see no value to using List<Dynamic> over Li
8 final Map<String, Dynamic> namedArguments;
9 ArgumentDescriptor(List<Dynamic> this.positionalArguments, Map<String, Dynami c> this.namedArguments);
zundel 2012/01/03 19:31:22 make namedArguments an optional parameter?
10 }
11
12 /**
13 An invocation mirror represents a particular invocation of a method. It includes the name of the method being
14 invoked and the arguments being sent. The receiver is not included, because the intent is that the receiver will in fact be the recipient of
15 the nosSuchMethod invocation that has an InvocationMirror as its argument.
16
17 Note the use of Dynamic in the types. Using Dynamic gives the user of this inter face the most flexibility to work with
18 the results without type warnings. Is this the best choice? Should we be more ac curate and use Object instead?
ahe 2012/01/02 16:21:14 I prefer Map<String, Dynamic> over Map<String, Obj
19
20 We avoid using a default factory for the interface. The reason is that the inter face is going to be part of the core library, while the
21 implementation is restricted to the mirror library. In turn, the rationale for r estricting the implementation is to prevent complications
22 in compilation to Javascript. In particular, avoiding complications during minif ication of code. For that reason, this interface may not
23 be implemented by user code.
ahe 2012/01/02 16:21:14 I don't see a reason to prevent this interface fro
24 */
25 interface InvocationMirror {
26 final String memberName;
27 final ArgumentDescriptor arguments;
28 final bool isGetter;
29 final bool isSetter;
30 final bool isMethod;
31
zundel 2012/01/03 19:31:22 Would it be appropriate to add 'isConstructor' ?
32 invokeOn(Object o);
33 }
34
35 /** Private class; implementation may vary. This is the perhaps the simplest var iant, but the VM
36 wants something easier to construct, that computes the properties instead of ju st storing them.
37 That is one more motivation for using InvocationMirror in noSuchMethod - the abi lity to abstract the
38 representation of a call site.
39 */
40 class _Invocation implements InvocationMirror {
41 final String memberName;
42 final ArgumentDescriptor arguments;
43 final _kind;
zundel 2012/01/03 19:31:22 why not type this as a String?
44 bool get isGetter() {return _kind === 'getter';}
45 bool get isSetter() {return _kind === 'setter';}
46 bool get isMethod() {return _kind === 'method';}
47
48 /** Need ObjectMirror API here, or some primitive; might look like */
49 invokeOn(Object o) {
50
51
52 ObjectMirror om = new ObjectMirror(o);
53 var result = om.invoke(memberName, arguments.positionalArguments, arguments.na medArguments).reflectee;
54 /** Thoughts on ObjectMirror: does API take failure functions, or do we rely on isolates?
55 Do we only support an invoke method, or do we have a separate API for running getters and setters?
56 I'd say the former.
57 */
58 }
59
60 _Invocation(this.memberName, this.arguments,
61 [bool getter = false, bool setter = false, bool method = true]
62 ): _kind = getter? 'getter': setter? 'setter' : 'method'
63 {
64 assert(getter?!setter && !method: setter? !method: method);
65 }
66 }
67
68
69 /** A simplified representation of stack traces.
70
71 // The idea is that we need to specify the type of a stack trace.
72 // Having an abstraction will allow us to support printing the stack nicely
73 // without exposing the internals of a frame, or the real mirrors on the stack.
74 // At the same time, who got called and with what arguments is available.
75 // It does prevent us from printing out the frame internals.
76 */
77 // typedef StackTraceMirror = List<InvocationMirror>
ahe 2012/01/02 16:21:14 I don't see how this typedef would make sense if w
78
OLDNEW
« no previous file with comments | « no previous file | mirrors/debug.dart » ('j') | mirrors/debug.dart » ('J')

Powered by Google App Engine
This is Rietveld 408576698