Setup getter and setter elements.

dart/frog/leg/emitter.dart

Index: dart/frog/leg/emitter.dart
diff --git a/dart/frog/leg/emitter.dart b/dart/frog/leg/emitter.dart
index 81539e589086aec983f996e329eec08d6ebd96c7..9e41c810dd87225a7d53218de8dd7d419e2155a2 100644
--- a/dart/frog/leg/emitter.dart
+++ b/dart/frog/leg/emitter.dart
@@ -52,10 +52,9 @@ function(child, parent) {
         String name = namer.getBailoutName(member);
         buffer.add('$prototype.$name = $codeBlock;\n');
       }
-    } else {
+    } else if (member.kind === ElementKind.FIELD) {
       // TODO(ngeoffray): Have another class generate the code for the
       // fields.
-      assert(member.kind === ElementKind.FIELD);
       if (compiler.universe.invokedSetters.contains(member.name)) {
         String setterName = namer.setterName(member.name);
         buffer.add('$prototype.$setterName = function(v){\n' +
@@ -66,6 +65,9 @@ function(child, parent) {
         buffer.add('$prototype.$getterName = function(){\n' +
           '  return this.${namer.getName(member)};\n}\n');
       }
+    } else {
+      compiler.internalError('unexpected kind: "${member.kind}"',
+                             element: member);

[ngeoffray, 2012/01/25 08:36:05]

Because that's the only place it's needed, and because we know that if we're
here, the node is available, I would prefer doing:
node: element.parseNode(compiler, compiler).

I am not convinced about the robustness of the 'position' method in Element
(what if someone starts cancelling on the element before it got parsed, or
resolved?). Therefore I would not provide the possibility of passing it an
element in the API.

[ahe, 2012/01/25 08:56:24]

I tried calling parseNode here, but noticed that I got a different error
message. This is what happened: parseFunction doesn't handle "get" or "set",
yet.

Moving forward, it would seem that we don't actually know that the node is
available at this point.

Regardless, it is a sound principle to keep error handling as simple as
possible. Invoking the parser just to report an error message does not seem like
a great idea to me anyways (but it was the first thing I thought of doing :-).

[ngeoffray, 2012/01/25 09:03:59]

Yeah, and I guess that's a bug: we're not putting in the work queue the
getter/setter.
I agree. Then we have to realize we must give up on giving a location if
cachedNode is null (which you do not check against in the 'position' methods).
You're just lucky that this is backed by a PartialElement that knows its initial
location :)

[ahe, 2012/01/25 09:07:14]

I'm not sure what situation you have in mind here. But let's talk more about
this when I arrive at the office.

     }
   }