Handle CALLBACKS correctly in IsProperty functions.
authorsvenpanne@chromium.org <svenpanne@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Tue, 28 Feb 2012 07:16:50 +0000 (07:16 +0000)
committersvenpanne@chromium.org <svenpanne@chromium.org@ce2b1a6d-e550-0410-aec6-3dcde31c8c00>
Tue, 28 Feb 2012 07:16:50 +0000 (07:16 +0000)
commit18ba22168eefc1d885fc1ae6953fa3430d29e33d
tree7eefd2b39bc7922be3743af46f38c0ebbfd88a0e
parent2350d11dacfc56d933f761dc4731768ca075ccac
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
src/objects-inl.h
src/objects.h
src/property-details.h
src/property.h