Handle CALLBACKS correctly in IsProperty functions.
With transitions in AccessorPairs, it is not enough to look at the PropertyType alone to decide whether we look at a property or not: For objects with JavaScript accessors, we have to look into the AccessorPair itself and see if one of its 2 parts is actually a JavaScript accessor. Therefore, a predicate with a PropertyType argument alone doesn't make sense anymore, we might need the associated value, too. Things are complicated by the fact that the holder in a LookupResult can be NULL, so we must be careful to retrieve its value only when it is really needed. To achieve the needed call-by-name semantics, a new Entry is introduced, which is basically a closure over a DescriptorArray and an index into this array (C++0x to the rescue!). GCC is clever enough to inline this class, so we pay no runtime penalty for this abstraction. It's all a bit ugly, but this is caused by the current structure of Descriptor, DescriptorArray and LookupResult: Things would be much easier if DescriptorArray were, well, an array of Descriptors, and LookupResult were a 'Maybe Descriptor' (in Haskell-terms). Review URL: https://chromiumcodereview.appspot.com/9466047 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10847 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Showing
Please
register
or
sign in
to comment