Chromium Code Reviews| OLD | NEW |
|---|---|
| (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 | |
| OLD | NEW |