Revised Mirrors proposal/take 3.

mirrors/corelib_mirrors.dart

Index: mirrors/corelib_mirrors.dart
===================================================================
--- mirrors/corelib_mirrors.dart	(revision 0)
+++ mirrors/corelib_mirrors.dart	(revision 0)
@@ -0,0 +1,78 @@
+#library("corelib_mirrors");
+#import("introspection.dart");
+
+/** This class should be part of the core library. 
+  It is used both in the Function interface and the InvocationMirror interface */
+class ArgumentDescriptor {
+   final List<Dynamic> positionalArguments;

[ahe, 2012/01/02 16:21:14]

Nit: I see no value to using List<Dynamic> over List.

+   final Map<String, Dynamic> namedArguments;
+   ArgumentDescriptor(List<Dynamic> this.positionalArguments, Map<String, Dynamic> this.namedArguments);

[zundel, 2012/01/03 19:31:22]

make namedArguments an optional parameter?

+}
+
+/**
+An invocation mirror represents a particular invocation of a method. It includes the name of the method being
+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 
+the nosSuchMethod invocation that has an InvocationMirror as its argument.
+
+Note the use of Dynamic in the types. Using Dynamic gives the user of this interface the most flexibility to work with 
+the results without type warnings. Is this the best choice? Should we be more accurate and use Object instead?

[ahe, 2012/01/02 16:21:14]

I prefer Map<String, Dynamic> over Map<String, Object>.

+
+We avoid using a default factory for the interface. The reason is that the interface is going to be part of the core library, while the
+implementation is restricted to the mirror library. In turn, the rationale for restricting the implementation is to prevent complications
+in compilation to Javascript. In particular, avoiding complications during minification of code. For that reason, this interface may not
+be implemented by user code.

[ahe, 2012/01/02 16:21:14]

I don't see a reason to prevent this interface from being implemented by user
code. A compiler to JS can simply warn and say that this requires an extra
symbol table.

+*/
+interface InvocationMirror  {
+ final String memberName;
+ final ArgumentDescriptor arguments;
+ final bool isGetter;
+ final bool isSetter;
+ final bool isMethod;
+

[zundel, 2012/01/03 19:31:22]

Would it be appropriate to add 'isConstructor' ?

+ invokeOn(Object o);
+}
+
+/** Private class; implementation may vary. This is the perhaps the simplest variant, but the VM 
+wants something easier to construct,  that computes the properties instead of just storing them.
+That is one more motivation for using InvocationMirror in noSuchMethod - the ability to abstract the
+representation of a call site.
+*/
+class _Invocation implements InvocationMirror {
+ final String memberName;
+ final ArgumentDescriptor arguments;
+ final _kind;

[zundel, 2012/01/03 19:31:22]

why not type this as a String?

+ bool get isGetter() {return _kind === 'getter';}
+ bool get isSetter() {return _kind === 'setter';}
+ bool get isMethod() {return _kind === 'method';}
+
+ /** Need ObjectMirror API here, or some primitive; might look like */
+ invokeOn(Object o) {
+
+
+  ObjectMirror om = new ObjectMirror(o);
+  var result = om.invoke(memberName, arguments.positionalArguments, arguments.namedArguments).reflectee;
+/** Thoughts on ObjectMirror: does API take failure functions, or do we rely on isolates? 
+   Do we only support an invoke method, or do we have a separate API for running getters and setters?
+   I'd say the former.
+*/
+ }
+
+_Invocation(this.memberName, this.arguments,
+                       [bool getter = false, bool setter = false, bool method = true]
+                     ): _kind = getter? 'getter': setter? 'setter' : 'method'
+  {
+       assert(getter?!setter && !method: setter? !method: method);
+   }
+}
+
+
+/** A simplified representation of stack traces.
+
+// The idea is that we need to specify the type of a stack trace. 
+// Having an abstraction will allow us to support printing the stack nicely
+// without exposing the internals of a frame, or the real mirrors on the stack.
+// At the same time, who got called and with what arguments is available.
+// It does prevent us from printing out the frame internals. 
+*/
+// typedef StackTraceMirror = List<InvocationMirror>

[ahe, 2012/01/02 16:21:14]

I don't see how this typedef would make sense if we supported this kind of
typedefs.

+