Implement Object.keys for proxies.

src/proxy.js

 // Copyright 2011 the V8 project authors. All rights reserved.
 // Redistribution and use in source and binary forms, with or without
 // modification, are permitted provided that the following conditions are
 // met:
 //
 //     * Redistributions of source code must retain the above copyright
 //       notice, this list of conditions and the following disclaimer.
 //     * Redistributions in binary form must reproduce the above
 //       copyright notice, this list of conditions and the following
 //       disclaimer in the documentation and/or other materials provided
@@ skipping 117 matching lines @@
     value: val,
     writable: true,
     enumerable: true,
     configurable: true});
   return true;
 }
 
 function DerivedHasTrap(name) {
   return !!this.getPropertyDescriptor(name)
 }
+
+function DerivedKeysTrap() {
+  return this.getOwnPropertyNames().filter(

[Mads Ager (chromium), 2011/07/12 13:28:19]

Is this specified in terms of filter and bind?

Is it supposed to work if the user overwrites filter, bind, getOwnPropertyNames,
getOwnPropertyDescriptor, etc?

Also, I think performance would be a lot better if you get the names in an array
and iterate through it directly.

[rossberg, 2011/07/13 10:11:52]

Yes, although it is not clear whether that is what they really _mean_. It's in
my list of open questions.
Well, `this' is the handler, and the latter two are other traps on the same
handler, so that's correct. Wrt filter and bind, it's probably not what they
really want.
Done.

+    function(name) {
+      return this.getOwnPropertyDescriptor('' + name).enumerable

[Mads Ager (chromium), 2011/07/12 13:28:19]

Do you need the string conversion here? Does getOwnPropertyNames ever return
somthing that is not a string? If so, consider using TO_STRING_INLINE(name) to
make this faster.

[rossberg, 2011/07/13 10:11:52]

Yes, that's actually a minor inconsistency in the current spec (which doesn't
have the conversion) that I reported -- getOwnPropertyNames is a user trap, so
it can return anything.

There are a few inconsistencies like that in the spec...
Done, but I have a question: doing TO_STRING_INLINE(names[i]) kept segfaulting
on me, until I found out that I better do "var name = names[i];
TO_STRING_INLINE(name)" instead. Is that a known (documented?) limitation?

[Mads Ager (chromium), 2011/07/13 10:17:25]

Yes, that is on purpose. The point is that TO_STRING_INLINE is a macro (defined
in macros.py) which has a fast case and a slow case. The macro duplicates the
argument and therefore we require it to be a variable to help ourselves avoid
repeating stuff with side effects.

+    }.bind(this));
+}