Support the literal kind for native classes (ie Console).

Support the literal kind for native classes (ie Console).
Committed: https://code.google.com/p/dart/source/detail?r=4935

[kasperl, 2012-03-02 13:11:32]

LGTM.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/emitter.dart
File frog/leg/emitter.dart (right):

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/emitter.dar...
frog/leg/emitter.dart:177: String attachTo(String name),
Does this mean that you're re-evaluating the native singleton expression over
and over again? Should you be caching it in a top-level variable instead so that
you never re-evaluate? Wouldn't that potentially make the code shorter too?

Do you really need this generality? Is there any case where attachTo doesn't
return something where name is a suffix?

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/emitter.dar...
frog/leg/emitter.dart:205: String name =
The name computation seems to be duplicated. Is there anyway to share that with
the getter part?

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
File frog/leg/native_emitter.dart (right):

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
frog/leg/native_emitter.dart:210: void generateNativeLiteral(
I think we usually put the first parameter on the previous line.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
frog/leg/native_emitter.dart:212: String nativeCode =
classElement.nativeName.slowToString();
String quotedNative = ...;
String nativeCode = quotedNative.substring(2, ...);

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
frog/leg/native_emitter.dart:246: } else if (isNativeGlobal(nativeName)) {
I would probably not make this an else if because of the return in the if. It
makes it look like the return is a mistake. I would even add a newline between
the first if (the returning one) and the next one and maybe comment on the
return.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_hand...
File frog/leg/native_handler.dart (right):

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_hand...
frog/leg/native_handler.dart:164: bool isNativeLiteral;
Initialize to false?

[ngeoffray, 2012-03-05 08:28:00]

Thanks Kasper for the comments. Let me know if you're OK with my replies.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/emitter.dart
File frog/leg/emitter.dart (right):

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/emitter.dar...
frog/leg/emitter.dart:177: String attachTo(String name),
On 2012/03/02 13:11:33, kasperl wrote:
> Does this mean that you're re-evaluating the native singleton expression over
> and over again? Should you be caching it in a top-level variable instead so
that
> you never re-evaluate? Wouldn't that potentially make the code shorter too?
> 
> Do you really need this generality? Is there any case where attachTo doesn't
> return something where name is a suffix?

There are three cases:
1) Normal:
        className.prototype.memberName

2) Native with hidden prototype:
        $dynamic(memberName).className

3) Native with singelton literal:
        className.memberName

Also, I am not sure about your comment on re-evaluating the native singleton?
What this code will do is something like:

ConsoleJs.log$0 = ConsoleJs.log
ConsoleJs.foo$2 = ConsoleJs.foo

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/emitter.dar...
frog/leg/emitter.dart:205: String name =
On 2012/03/02 13:11:33, kasperl wrote:
> The name computation seems to be duplicated. Is there anyway to share that
with
> the getter part?

I could share it, but that means it would be computed even in the case where
neither the getter and setter must be generated.

I think long-term we want the field case to be handled just like other members.
That's the TODO line 202 of the unchanged file. I'll add back the TODO.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
File frog/leg/native_emitter.dart (right):

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
frog/leg/native_emitter.dart:210: void generateNativeLiteral(
On 2012/03/02 13:11:33, kasperl wrote:
> I think we usually put the first parameter on the previous line.

Done.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
frog/leg/native_emitter.dart:212: String nativeCode =
classElement.nativeName.slowToString();
On 2012/03/02 13:11:33, kasperl wrote:
> String quotedNative = ...;
> String nativeCode = quotedNative.substring(2, ...);

Done.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_emit...
frog/leg/native_emitter.dart:246: } else if (isNativeGlobal(nativeName)) {
On 2012/03/02 13:11:33, kasperl wrote:
> I would probably not make this an else if because of the return in the if. It
> makes it look like the return is a mistake. I would even add a newline between
> the first if (the returning one) and the next one and maybe comment on the
> return.

Done.

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_hand...
File frog/leg/native_handler.dart (right):

https://chromiumcodereview.appspot.com/9583006/diff/1005/frog/leg/native_hand...
frog/leg/native_handler.dart:164: bool isNativeLiteral;
On 2012/03/02 13:11:33, kasperl wrote:
> Initialize to false?

Thanks for spotting this. I was convinced it would be initialized to false
because of habits that should no longer stand.

[kasperl, 2012-03-05 08:29:28]

Thanks for the update. Still LGTM.