18ba22168e
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 |
||
---|---|---|
benchmarks | ||
build | ||
include | ||
preparser | ||
samples | ||
src | ||
test | ||
tools | ||
.gitignore | ||
AUTHORS | ||
ChangeLog | ||
LICENSE | ||
LICENSE.strongtalk | ||
LICENSE.v8 | ||
LICENSE.valgrind | ||
Makefile | ||
SConstruct |