github
/
duktape
mirror of https://github.com/svaarala/duktape.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

special->exotic renaming in internal docs

pull/9/head
Sami Vaarala 11 years ago
parent
fe833655ec
commit
4e9de85258
4 changed files with 220 additions and 220 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 38
      doc/arguments-object.txt
  2. 264
      doc/hobject-algorithms.txt
  3. 134
      doc/hobject-design.txt
  4. 4
      doc/hobject-enumeration.txt

38
doc/arguments-object.txt
View File

@ -12,7 +12,7 @@ The arguments object is created during function entry, as part of declaration
binding instantiation (Section 10.5), and is bound to the ``arguments``
identifier unless a shadowing declaration exists. It is then accessed by
program code through the bound identifier ``arguments``. The arguments
object and its special properties and behavior is described in E5 Section
object and its exotic properties and behavior is described in E5 Section
10.6.
An arguments object created for a strict callee (referred to as a
@ -25,7 +25,7 @@ An arguments object created for a non-strict callee (referred to as a
It has non-standard variants for many core algorithms:
``[[Get]]``, ``[[GetOwnProperty]]``, ``[[DefineOwnProperty]]``,
``[[Delete]]``. The non-standard variants provide the following main
special behaviors:
exotic behaviors:
* **Magic argument bindings**: numbered indices ("0", "1", ...) matching
formal arguments are "magically" bound to the corresponding variables.
@ -66,8 +66,8 @@ Object type and internal flags
* Object class: ``Arguments``
* Internal prototype: standard built-in Object prototype
* The ``DUK_HOBJECT_FLAG_SPECIAL_ARGUMENTS`` flag needs to be set for
non-strict arguments object instances. This flag enables the special
* The ``DUK_HOBJECT_FLAG_EXOTIC_ARGUMENTS`` flag needs to be set for
non-strict arguments object instances. This flag enables the exotic
variable map and ``caller`` post-check behaviors.
Although the arguments object looks like an array, it is a normal object.
@ -85,7 +85,7 @@ formal arguments declared):
| Property | Non-strict mode | Strict mode |
+=============+===========================+================================+
| indexes | Actual call arguments. | Actual call arguments. |
| [0,nargs[ | Special behavior for those| No special behavior. |
| [0,nargs[ | Exotic behavior for those | No exotic behavior. |
| | magically bound to formal | |
| | arguments. | |
+-------------+---------------------------+--------------------------------+
@ -101,7 +101,7 @@ formal arguments declared):
| | | shared function. |
+-------------+---------------------------+--------------------------------+
| ``caller`` | Not set. | Accessor property with setter |
| | Still, special behavior | and getter set to the |
| | Still, exotic behavior | and getter set to the |
| | for ``[[Get]]`` if later | ``[[ThrowTypeError]]`` |
| | assigned value is a strict| shared function. |
| | function instance. | |
@ -208,7 +208,7 @@ The arguments object and its parameter map would be something like::
}
Note that the magic bindings *do not keep* variables and the corresponding
arguments object entries in perfect sync, although the special behavior
arguments object entries in perfect sync, although the exotic behavior
tries to hide this from the program. For instance::
function f(x) {
@ -222,7 +222,7 @@ tries to hide this from the program. For instance::
// ... however, this is not externally visible. The following
// prints '2'. The initial property lookup returns 1, but the
// special [[GetOwnProperty]] behavior overwrites the value with
// exotic [[GetOwnProperty]] behavior overwrites the value with
// the current value of 'x'.
print(arguments[0]);
@ -339,17 +339,17 @@ deletions), it could be deleted from the arguments object along with
the variable environment reference. This is not worth while: this
does not happen in relevant cases and would require additional checks.
Special [[Get]] behavior
========================
Exotic [[Get]] behavior
=======================
A non-strict arguments object has a special ``[[Get]]`` implementation.
This is unusual, because most special behaviors are defined through a
A non-strict arguments object has a exotic ``[[Get]]`` implementation.
This is unusual, because most exotic behaviors are defined through a
custom ``[[GetOwnProperty]]`` or ``[[DefineOwnProperty]``. Because
this special behavior operates at the ``[[Get]]`` level, it affects
this exotic behavior operates at the ``[[Get]]`` level, it affects
the reading of property values, but is not visible through property
descriptors or e.g. ``[[GetOwnProperty]]``.
The special behavior is covered in E5 Section 10.6, description for
The exotic behavior is covered in E5 Section 10.6, description for
``[[Get]]``. To summarize, if:
* the property being looked up is not currently mapped in the
@ -373,7 +373,7 @@ strict.
However, the ``caller`` property *can* be read through e.g.
``Object.getOwnPropertyDescriptor()`` (which uses
``[[GetOwnProperty]]``). The special behavior does not protect
``[[GetOwnProperty]]``). The exotic behavior does not protect
against this because the check is at the ``[[Get]]`` level.
Example::
@ -386,15 +386,15 @@ Example::
// this is OK
print(Object.getOwnPropertyDescriptor(a, "caller"));
// this fails due to special behavior
// this fails due to exotic behavior
// (though doesn't in Rhino, V8, or Smjs)
print(a.caller);
Finally, this special behavior is puzzling because a non-strict
Finally, this exotic behavior is puzzling because a non-strict
mode arguments object *does not even have* a ``caller`` property.
The strict mode arguments object does have a ``caller`` property,
but it is a "``TypeError`` thrower", and strict mode arguments
objects don't have any special behavior (like ``[[Get]]`` here).
objects don't have any exotic behavior (like ``[[Get]]`` here).
Function objects and argument creation
======================================
@ -569,6 +569,6 @@ of an arguments object are beyond the range of "valid array indices"
(see ``hobject-design.txt`` for detailed discussion).
The current implementation assumes that this never happens in practice.
As a result, arguments special behavior can do a fast reject if the
As a result, arguments exotic behavior can do a fast reject if the
key being accessed is not a valid array index.

264
doc/hobject-algorithms.txt
View File

@ -12,8 +12,8 @@ This document discusses, in detail, the internal algorithms for dealing
with objects, in particular for object property access. These algorithms
are based on the algorithm descriptions in the E5 specification, which
have been refined towards the practical implementation needs e.g. by
combining multiple algorithms, inlining calls, and inlining "special
behaviors".
combining multiple algorithms, inlining calls, and inlining "exotic
behaviors" (term borrowed from ES6).
The intent is to describe versions of the conceptual algorithms most suited
for implementation, without actually going into implementation level details.
@ -33,7 +33,7 @@ Related sections of E5 specification
For raw property algorithms:
* E5 Section 8.12: the default algorithms
* E5 Section 8.6.2: one paragraph lists special behaviors (page 33, PDF page 43)
* E5 Section 8.6.2: one paragraph lists exotic behaviors (page 33, PDF page 43)
* E5 Section 10.6: arguments object
* E5 Section 15.5.5.2: String object
* E5 Section 15.3.4.5.3, 15.3.5.3, 15.3.5.4: Function object
@ -60,9 +60,9 @@ Algorithm overview
Ecmascript object property access behavior is described by internal property
handling algorithms. The default algorithms are described in E5 Section 8.12.
There are some objects with special behaviors; these have variants of the
There are some objects with exotic behaviors; these have variants of the
default property handling algorithms. See ``hobject-design.txt`` for a
detailed discussion of special behaviors.
detailed discussion of exotic behaviors.
The "raw" property algorithms are:
@ -80,7 +80,7 @@ The "raw" property algorithms are:
* Modified behavior for: Function object (E5 Section 15.3.5.4)
* Note that special behaviors of ``[[Get]]`` are '''not''' visible through property
* Note that exotic behaviors of ``[[Get]]`` are '''not''' visible through property
descriptors at all.
* The default ``[[CanPut]](P)`` algorithm (E5 Section 8.12.1)
@ -105,7 +105,7 @@ The "raw" property algorithms are:
The following figure illustrates the caller-callee relationship between the
default property algorithms (the figure would be somewhat different for
special behavior variants)::
exotic behavior variants)::
[[Put]]
|
@ -155,9 +155,9 @@ an easy answer in the E5 specification, e.g.:
* What do the internal algorithms look like after you "inline" the calls
used in the specification (which often obscure the true semantics)?
* What do the internal algorithms look like if special behaviors are
* What do the internal algorithms look like if exotic behaviors are
"inlined" into one algorithm which supports both the default and all the
special behaviors?
exotic behaviors?
* What do the internal algorithms look like once we add "fast paths" for
array index access (where the fast path avoids string interning if
@ -425,16 +425,16 @@ Notes
+ Variable declaration initializer
+ ``for`` and ``for-in`` statements
Special behaviors
=================
Exotic behaviors
================
This section covers the standard algorithms with special behaviors inlined.
For each algorithm, a single algorithm with all special behaviors inlined
This section covers the standard algorithms with exotic behaviors inlined.
For each algorithm, a single algorithm with all exotic behaviors inlined
is presented. Calls to other internal algorithms are not inlined; the
purpose is to clarify how the special behaviors can be implemented
purpose is to clarify how the exotic behaviors can be implemented
reasonably.
Note: the ``String`` object has no special behaviors as such, but the
Note: the ``String`` object has no exotic behaviors as such, but the
``length`` and array index properties are implemented as virtual properties,
so they are inlined into the algorithms below.
@ -474,12 +474,12 @@ Default algorithm
8. Return ``D``.
Adding String object special behavior
:::::::::::::::::::::::::::::::::::::
Adding String object exotic behavior
::::::::::::::::::::::::::::::::::::
Now consider the ``String`` variant in E5 Section 15.5.5.2. Step 2 states that if
the default algorithm returns a descriptor (not undefined), the special behavior
does not execute at all. That, is the special algorithm is skipped if ``O`` has
the default algorithm returns a descriptor (not undefined), the exotic behavior
does not execute at all. That, is the exotic algorithm is skipped if ``O`` has
an "own property" for key ``P``.
If the default algorithm fails to find an own property, the variant kicks in
@ -494,14 +494,14 @@ value.
array index, any number-like value will do. This allows strings
longer than 4G. The algorithms here don't reflect this correctly.
The ``String`` object ``length`` property is an ordinary (non-special)
The ``String`` object ``length`` property is an ordinary (non-exotic)
property, see E5 Section 15.5.5.1. However, it is non-writable and
non-configurable (and even non-enumerable), so it too is nice and easy
to implement as a special property. We'll thus incorporate the ``length``
to implement as a exotic property. We'll thus incorporate the ``length``
property into the algorithm.
Finally note that from an implementation perspective it might be easier
to check for the special (virtual) properties before looking at the actual
to check for the exotic (virtual) properties before looking at the actual
ones (i.e. reverse the order of checking). This seems perfectly OK to do,
because *if* the property name matches a virtual property, the object cannot
have a "normal" property of the same name: the initial ``String`` object
@ -518,7 +518,7 @@ after the normal property check is as follows:
a. If ``O`` is not a ``String`` instance, return ``undefined``.
b. (``String`` object special behavior.)
b. (``String`` object exotic behavior.)
Let ``str`` be the String value of the ``[[PrimitiveValue]]``
internal property of ``O`` and ``len`` be the number of
characters in ``str``.
@ -570,11 +570,11 @@ after the normal property check is as follows:
8. Return ``D``.
Adding arguments object special behavior
::::::::::::::::::::::::::::::::::::::::
Adding arguments object exotic behavior
:::::::::::::::::::::::::::::::::::::::
Next, consider the special ``[[GetOwnProperty]]`` behavior for a non-strict
arguments object described in E5 Section 10.6. The special behavior only
Next, consider the exotic ``[[GetOwnProperty]]`` behavior for a non-strict
arguments object described in E5 Section 10.6. The exotic behavior only
applies if the object *did* contain the own property ``P``, and possibly
modifies the looked up value if the key ``P`` matches a numeric index
magically "bound" to a formal.
@ -583,16 +583,16 @@ Note that the property descriptors for such variables are initially data
property descriptors, so the default algorithm will find a data property
descriptor (and not an accessor property descriptor). If the property is
later converted to an accessor, the magical variable binding is also
dropped. So, if the special behavior activates, the property is always
dropped. So, if the exotic behavior activates, the property is always
a data property.
The special behavior can be appended to the above algorithm as follows:
The exotic behavior can be appended to the above algorithm as follows:
1. If ``O`` doesn’t have an own property with name ``P``:
a. If ``O`` is not a ``String`` instance, return ``undefined``.
b. (``String`` object special behavior.)
b. (``String`` object exotic behavior.)
Let ``str`` be the String value of the ``[[PrimitiveValue]]``
internal property of ``O`` and ``len`` be the number of
characters in ``str``.
@ -645,7 +645,7 @@ The special behavior can be appended to the above algorithm as follows:
8. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. Let ``isMapped`` be the result of calling the ``[[GetOwnProperty]]``
@ -661,14 +661,14 @@ The special behavior can be appended to the above algorithm as follows:
Notes:
* Step 1.b: if the object is a ``String`` object, there is no need for the
arguments object special behavior check in step 8: an object can never be
arguments object exotic behavior check in step 8: an object can never be
a ``String`` object and an arguments object simultaenously.
* Step 8: arguments objects for strict mode functions don't have the special
* Step 8: arguments objects for strict mode functions don't have the exotic
behavior (or a ``[[ParameterMap]]``). Arguments objects for non-strict
functions don't always have special behavior either: they only do, if there
functions don't always have exotic behavior either: they only do, if there
is at least one mapped variable. If so, ``[[ParameterMap]]`` is added, and
special behavior is enabled. See the main algorithm in E5 Section 10.6,
exotic behavior is enabled. See the main algorithm in E5 Section 10.6,
step 12.
* Step 8.c.1: this step invokes an internal getter function which looks up
@ -680,7 +680,7 @@ Notes:
at this point the property is always a data property, so setting the
``[[Value]]`` is correct. If a magically bound value is converted into an
accessor, the property is deleted from the ``[[ParameterMap]]`` so it no
longer has special behavior.
longer has exotic behavior.
Final version
:::::::::::::
@ -692,7 +692,7 @@ Final version with some cleanup and simplification:
a. If ``O`` is not a ``String`` instance, return ``undefined``.
b. (``String`` object special behavior.)
b. (``String`` object exotic behavior.)
Let ``str`` be the String value of the ``[[PrimitiveValue]]``
internal property of ``O`` and ``len`` be the number of
characters in ``str``.
@ -743,7 +743,7 @@ Final version with some cleanup and simplification:
3. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -787,14 +787,14 @@ Default algorithm
6. Return the result calling the ``[[Call]]`` internal method of ``getter``
providing ``O`` as the ``this`` value and providing no arguments.
Adding Function object special behavior
:::::::::::::::::::::::::::::::::::::::
Adding Function object exotic behavior
::::::::::::::::::::::::::::::::::::::
Consider the ``Function`` variant in E5 Section 15.3.5.4. The behavior only
applies if ``P`` is ``caller`` and the resulting return *value* of the default
function is a strict mode function.
The special behavior does not need to be checked in steps 2 or 5 of the
The exotic behavior does not need to be checked in steps 2 or 5 of the
default algorithm, because ``undefined`` is never a strict mode function
value.
@ -824,15 +824,15 @@ So, we can reformulate into:
6. Return ``res``.
Adding arguments object special behavior
::::::::::::::::::::::::::::::::::::::::
Adding arguments object exotic behavior
:::::::::::::::::::::::::::::::::::::::
Next, consider the special ``[[Get]]`` behavior for a non-strict arguments
object described in E5 Section 10.6. To be exact, the special behaviors
Next, consider the exotic ``[[Get]]`` behavior for a non-strict arguments
object described in E5 Section 10.6. To be exact, the exotic behaviors
are only enabled for objects with a non-empty initial ``[[ParameterMap]]``
(see E5 Section 10.6, main algorithm, step 12).
There are two special behaviors:
There are two exotic behaviors:
1. If the property name ``P`` is magically bound to an identifier
(through the ``[[ParameterMap]]``) the default ``[[Get]]`` is
@ -841,7 +841,7 @@ There are two special behaviors:
case, so no side effects are lost by this behavior.)
2. If the property name ``P`` is *not bound* to an identifier,
the ``"caller"`` property has special behavior essentially
the ``"caller"`` property has exotic behavior essentially
identical to that of ``Function``.
These can be incorporated as follows:
@ -849,7 +849,7 @@ These can be incorporated as follows:
1. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. Let ``isMapped`` be the result of calling the ``[[GetOwnProperty]]``
@ -882,7 +882,7 @@ These can be incorporated as follows:
6. If ``O`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -894,7 +894,7 @@ Note:
the property value is an own data property. Magically bound properties
are initially own data properties, and if they're changed to accessors
(or deleted), the binding is removed. Because of this, the arguments
special behavior could just as well be moved to the end of the algorithm.
exotic behavior could just as well be moved to the end of the algorithm.
Final version
:::::::::::::
@ -904,7 +904,7 @@ Final version with some cleanup and simplification:
1. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -935,7 +935,7 @@ Final version with some cleanup and simplification:
6. If ``O`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -950,14 +950,14 @@ Related E5 sections:
* E5 Section 15.4.5: ``Array``
* E5 Section 10.5: arguments object
Note that ``String`` special properties are taken into account by
Note that ``String`` exotic properties are taken into account by
``[[DefineOwnProperty]]`` through ``[[GetOwnProperty]]`` which
returns a property descriptor prohibiting any property value or
attribute changes. However, no explicit checks are needed for
these (virtual) properties.
This is by the far the most complex property algorithm, especially
with special behaviors incorporated. The algorithm itself is
with exotic behaviors incorporated. The algorithm itself is
complex, but the ``Array`` variant actually makes multiple calls to
the default variant which is even trickier for "inlining".
@ -1081,7 +1081,7 @@ Notes:
from the description.
* There are multiple exit points for both Reject (throw or return false) and
true. For incorporating inline special behaviors, these are turned to
true. For incorporating inline exotic behaviors, these are turned to
"gotos" below.
Default algorithm reformulated
@ -1207,7 +1207,7 @@ However, it's much more complex than that, because the variant algorithm
makes multiple calls to the default algorithm.
Let's look at the variant algorithm first (here we assume ``O`` is an
``Array`` with special behavior, so no check is made for special behavior):
``Array`` with exotic behavior, so no check is made for exotic behavior):
1. Let ``oldLenDesc`` be the result of calling the ``[[GetOwnProperty]]``
internal method of ``O`` passing ``"length"`` as the argument. The
@ -1492,8 +1492,8 @@ and outputs:
* success flag (``false`` if some element couldn't be deleted)
* final array length to be updated into ``"length"`` property
Adding ``Array`` object special behavior
::::::::::::::::::::::::::::::::::::::::
Adding ``Array`` object exotic behavior
:::::::::::::::::::::::::::::::::::::::
Incorporating the approach for adding a pre- and post-processing phase
we get something like:
@ -1681,10 +1681,10 @@ we get something like:
Throw a ``RangeError`` exception. Note that this is unconditional
(thrown even if ``Throw`` is ``false``).
Adding arguments object special behavior
::::::::::::::::::::::::::::::::::::::::
Adding arguments object exotic behavior
:::::::::::::::::::::::::::::::::::::::
The special ``[[DefineOwnProperty]]`` behavior for an arguments object
The exotic ``[[DefineOwnProperty]]`` behavior for an arguments object
containing a ``[[ParameterMap]]`` is described in E5 Section 10.6.
The variant algorithm essentially first runs the default algorithm.
@ -1938,10 +1938,10 @@ Default algorithm
5. Return ``false``.
Adding arguments object special behavior
::::::::::::::::::::::::::::::::::::::::
Adding arguments object exotic behavior
:::::::::::::::::::::::::::::::::::::::
The special ``[[Delete]]`` behavior for an arguments object containing a
The exotic ``[[Delete]]`` behavior for an arguments object containing a
``[[ParameterMap]]`` is described in E5 Section 10.6.
The variant algorithm essentially first runs the default algorithm.
@ -2181,7 +2181,7 @@ GetProperty
``[[GetOwnProperty]]`` which follows the prototype chain. Like
``[[GetOwnProperty]]``, it returns a descriptor.
There is no special behavior for ``[[GetProperty]]``, the special behaviors
There is no exotic behavior for ``[[GetProperty]]``, the exotic behaviors
only affect ``[[GetOwnProperty]]`` which is called during ``[[GetProperty]]``.
Original algorithm
@ -2250,7 +2250,7 @@ GetProperty with default GetOwnProperty inlined
:::::::::::::::::::::::::::::::::::::::::::::::
``[[GetOwnProperty]]`` is just creating the descriptor from whatever form
properties are stored. It has special behaviors, so the resulting function
properties are stored. It has exotic behaviors, so the resulting function
is a bit complicated.
The inlined form for default ``[[GetOwnProperty]]`` is essentially:
@ -2291,12 +2291,12 @@ The inlined form for default ``[[GetOwnProperty]]`` is essentially:
5. Return ``undefined``
This is a relatively useless form, because special behaviors are missing.
This is a relatively useless form, because exotic behaviors are missing.
GetProperty with complete GetOwnProperty inlined
::::::::::::::::::::::::::::::::::::::::::::::::
The following inlines ``[[GetOwnProperty]]`` with all special behaviors:
The following inlines ``[[GetOwnProperty]]`` with all exotic behaviors:
1. ``curr`` = ``O``
@ -2306,7 +2306,7 @@ The following inlines ``[[GetOwnProperty]]`` with all special behaviors:
a. If ``curr`` is not a ``String`` instance, goto NOTFOUND.
b. (``String`` object special behavior.)
b. (``String`` object exotic behavior.)
Let ``str`` be the String value of the ``[[PrimitiveValue]]``
internal property of ``O`` and ``len`` be the number of
characters in ``str``.
@ -2357,7 +2357,7 @@ The following inlines ``[[GetOwnProperty]]`` with all special behaviors:
4. If ``curr`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -2389,7 +2389,7 @@ Get
Get with GetProperty inlined
----------------------------
``[[Get]]`` was covered above when discussion special behaviors, so we'll
``[[Get]]`` was covered above when discussion exotic behaviors, so we'll
skip discussing it again here.
``[[Get]]`` is essentially a ``[[GetProperty]]`` followed by coercion of
@ -2399,12 +2399,12 @@ function. The descriptor does not need to be created at all, as we're
just interested in the final value.
The following combines both ``[[GetOwnProperty]]`` and ``[[Get]]`` with
special behaviors:
exotic behaviors:
1. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -2421,7 +2421,7 @@ special behaviors:
a. If ``curr`` is not a ``String`` instance, goto NOTFOUND.
b. (``String`` object special behavior.)
b. (``String`` object exotic behavior.)
Let ``str`` be the String value of the ``[[PrimitiveValue]]``
internal property of ``O`` and ``len`` be the number of
characters in ``str``.
@ -2429,8 +2429,8 @@ special behaviors:
c. If ``P`` is ``"length"``:
1. Return ``len`` (a primitive number).
(No need to check for arguments object special
behavior or ``"caller"`` property special behavior.)
(No need to check for arguments object exotic
behavior or ``"caller"`` property exotic behavior.)
d. If ``P`` is an array index (E5 Section 15.4):
@ -2440,8 +2440,8 @@ special behaviors:
a. Return a primitive string of length 1, containing one character
from ``str`` at position ``index`` (zero based index).
(No need to check for arguments object special behavior or
``"caller"`` property special behavior.)
(No need to check for arguments object exotic behavior or
``"caller"`` property exotic behavior.)
e. Goto NOTFOUND.
@ -2458,9 +2458,9 @@ special behaviors:
b. If ``getter`` is ``undefined``:
1. Return ``undefined``.
(Note: arguments object special behavior for mapped variables cannot
(Note: arguments object exotic behavior for mapped variables cannot
apply: if the property is an accessor, it can never be in the arguments
object ``[[ParameterMap]]``. Also, the ``"caller"`` special behavior
object ``[[ParameterMap]]``. Also, the ``"caller"`` exotic behavior
does not apply, since the result ``undefined`` is not a strict mode
function. Thus, no "goto FOUND1" here.)
@ -2469,16 +2469,16 @@ special behaviors:
providing no arguments.
d. Goto FOUND2.
(Note: arguments object special behavior for mapped variables cannot
(Note: arguments object exotic behavior for mapped variables cannot
apply: if the property is an accessor, it can never be in the arguments
object ``[[ParameterMap]]``. However, the ``"caller"`` special behavior
object ``[[ParameterMap]]``. However, the ``"caller"`` exotic behavior
might apply, at FOUND2.)
6. **FOUND1**:
If ``curr`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -2491,7 +2491,7 @@ special behaviors:
If ``O`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -2504,7 +2504,7 @@ special behaviors:
10. If ``curr`` is not ``null``, goto NEXT.
11. Return ``undefined``.
(Note: no need for special behavior checks here; e.g. result is not a
(Note: no need for exotic behavior checks here; e.g. result is not a
strict mode function.)
.. note:: The step 5.c gives the object as the ``this`` binding for the
@ -2547,10 +2547,10 @@ internal algorithms:
* ``[[Put]]``, E5 Section 8.12.5
* Array's special ``[[DefineOwnProperty]]`` relies on the default one, E5
* Array's exotic ``[[DefineOwnProperty]]`` relies on the default one, E5
Section 15.4.5.1
* Argument object's special ``[[DefineOwnProperty]]`` relies on the default
* Argument object's exotic ``[[DefineOwnProperty]]`` relies on the default
one, E5 Section 10.6
It is used less fundamentally in many places, e.g. to initialize values
@ -2630,7 +2630,7 @@ More specifically, we know that in the ``[[DefineOwnProperty]]`` algorithm:
* ``IsDataDescriptor(Desc)`` is ``true``
* ``IsAccessorDescriptor(Desc)`` is ``false``
Taking the ``[[DefineOwnProperty]]`` with all special behaviors included,
Taking the ``[[DefineOwnProperty]]`` with all exotic behaviors included,
using the above assumptions, eliminating any unnecessary steps, cleaning
up and clarifying, we get:
@ -2687,7 +2687,7 @@ up and clarifying, we get:
4. Return ``true``.
Note that step 1 combines the pre-step and post-step for an ``Array``
object ``length`` special behavior. This is only possible if we know
object ``length`` exotic behavior. This is only possible if we know
beforehand that the ``"length"`` property is writable (so that the
write never fails and we always reach the post-step).
@ -2777,7 +2777,7 @@ More specifically, we know that in the ``[[DefineOwnProperty]]`` algorithm:
* ``current`` is ``undefined``
Taking the ``[[DefineOwnProperty]]`` with all special behaviors included,
Taking the ``[[DefineOwnProperty]]`` with all exotic behaviors included,
using the above assumptions, and then eliminating any unnecessary steps,
cleaning up and clarifying, we get:
@ -2829,7 +2829,7 @@ cleaning up and clarifying, we get:
If ``Throw`` is ``true``, then throw a ``TypeError`` exception,
otherwise return ``false``.
This can be refined further by noticing that the arguments object special
This can be refined further by noticing that the arguments object exotic
behavior cannot be triggered if the property does not exist: all magically
bound properties exist initially, and if they are deleted, the magic
variable binding is also deleted.
@ -2932,7 +2932,7 @@ the possibilities a great deal. Here we assume that:
* Object is extensible
* Property does not exist
* Property does not have special behavior and is not virtual
* Property does not have exotic behavior and is not virtual
* Property descriptor is a data descriptor, which is fully populated
With these assumptions, eliminating any unnecessary steps, the algorithm is
@ -3325,7 +3325,7 @@ be non-null in the first loop):
Note about PutValue
:::::::::::::::::::
Note that ``PutValue()`` has a ``[[Put]]`` variant with two special
Note that ``PutValue()`` has a ``[[Put]]`` variant with two exotic
behaviors related to object coercion. The above algorithm does not
take those into account.
@ -3704,7 +3704,7 @@ Section 9.9, ``ToObject()``).
Note: the replacement ``[[Get]]`` overrides whatever ``[[Get]]`` function
would normally be used for the target object. For instance, if there were
some primitive-to-object coercion which created an arguments object, the
arguments object special ``[[Get]]`` behavior would be skipped. However,
arguments object exotic ``[[Get]]`` behavior would be skipped. However,
since the arguments and ``Function`` objects are the only objects with
non-default ``[[Get]]``, this is not an issue in practice.
@ -3741,7 +3741,7 @@ and property name value ``P``):
5. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -3774,7 +3774,7 @@ and property name value ``P``):
10. If ``orig`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -3792,7 +3792,7 @@ Notes:
* Step 4 comes from ``GetValue()``.
* Steps 5 and forward come from ``[[Get]]``; here with special behaviors
* Steps 5 and forward come from ``[[Get]]``; here with exotic behaviors
inlined, but ``[[GetProperty]]`` not inlined.
We could inline the ``[[GetProperty]]`` call to the algorithm. However,
@ -3828,7 +3828,7 @@ A variant where steps 3 and 4 are reversed and expanded is as follows:
4. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -3861,7 +3861,7 @@ A variant where steps 3 and 4 are reversed and expanded is as follows:
9. If ``orig`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -3928,7 +3928,7 @@ can be worked into the algorithm e.g. as follows:
4. If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -3961,7 +3961,7 @@ can be worked into the algorithm e.g. as follows:
9. If ``orig`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -4022,7 +4022,7 @@ This variant is as follows:
If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -4055,7 +4055,7 @@ This variant is as follows:
9. If ``orig`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -4077,7 +4077,7 @@ A simple "shallow fast path" could be:
* If ``P`` is a whole number in the range [0,2**32-2] (a valid array index)
AND ``O`` has an array part
AND ``O`` has no conflicting "special behaviors", then:
AND ``O`` has no conflicting "exotic behaviors", then:
+ Let ``idx`` be the array index represented by ``P``
@ -4094,8 +4094,8 @@ Some notes:
assumption of a number as a property name, with the target property
present as an "own data property" of the target object.
* The conflicting special behaviors are currently: ``String`` object special
behavior, and arguments object special behavior. Array special behaviors
* The conflicting exotic behaviors are currently: ``String`` object exotic
behavior, and arguments object exotic behavior. Array exotic behaviors
are not conflicting for read operations.
* A certain key in the array can be defined even if the value is ``undefined``.
@ -4168,8 +4168,8 @@ altogether produces:
1. Array fast path: If ``O`` is an object (always true here)
AND ``P`` is a number and a valid array index (whole number in [0,2**32-2])
AND ``O`` internal representation has an array part
AND ``O`` does not have conflicting special behaviors (cannot have
``String`` or arguments special behaviors, may have ``Array``
AND ``O`` does not have conflicting exotic behaviors (cannot have
``String`` or arguments exotic behaviors, may have ``Array``
behavior), then:
a. Let ``idx`` be the array index represented by ``P``
@ -4193,7 +4193,7 @@ altogether produces:
If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -4226,7 +4226,7 @@ altogether produces:
9. If ``orig`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -4284,8 +4284,8 @@ is a primitive string (in step 2.d):
1. Array fast path: If ``O`` is an object (always true here)
AND ``P`` is a number and a valid array index (whole number in [0,2**32-2])
AND ``O`` internal representation has an array part
AND ``O`` does not have conflicting special behaviors (cannot have
``String`` or arguments special behaviors, may have ``Array``
AND ``O`` does not have conflicting exotic behaviors (cannot have
``String`` or arguments exotic behaviors, may have ``Array``
behavior), then:
a. Let ``idx`` be the array index represented by ``P``
@ -4309,7 +4309,7 @@ is a primitive string (in step 2.d):
If ``O`` is an ``arguments`` object which contains a ``[[ParameterMap]]``
internal property:
a. (Arguments object special behavior.) Let ``map`` be the value of
a. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
b. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -4342,13 +4342,13 @@ is a primitive string (in step 2.d):
9. If ``orig`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
10. Return ``res``.
We can also move step 4 (arguments special behavior) to step 2.e. This has
We can also move step 4 (arguments exotic behavior) to step 2.e. This has
the problem that step 4 assumes ``P`` has been string coerced already. So,
a duplicate coercion is needed (like for strings):
@ -4401,8 +4401,8 @@ a duplicate coercion is needed (like for strings):
1. Array fast path: If ``O`` is an object (always true here)
AND ``P`` is a number and a valid array index (whole number in [0,2**32-2])
AND ``O`` internal representation has an array part
AND ``O`` does not have conflicting special behaviors (cannot have
``String`` or arguments special behaviors, may have ``Array``
AND ``O`` does not have conflicting exotic behaviors (cannot have
``String`` or arguments exotic behaviors, may have ``Array``
behavior), then:
a. Let ``idx`` be the array index represented by ``P``.
@ -4419,7 +4419,7 @@ a duplicate coercion is needed (like for strings):
a. Set ``P`` to ``ToString(P)``.
b. (Arguments object special behavior.) Let ``map`` be the value of
b. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
c. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -4463,7 +4463,7 @@ a duplicate coercion is needed (like for strings):
8. If ``orig`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -4530,8 +4530,8 @@ and using ``curr`` instead of ``O`` otherwise, we get:
2. Array fast path: If ``O`` is an object (always true here)
AND ``P`` is a number and a valid array index (whole number in [0,2**32-2])
AND ``O`` internal representation has an array part
AND ``O`` does not have conflicting special behaviors (cannot have
``String`` or arguments special behaviors, may have ``Array``
AND ``O`` does not have conflicting exotic behaviors (cannot have
``String`` or arguments exotic behaviors, may have ``Array``
behavior), then:
a. Let ``idx`` be the array index represented by ``P``.
@ -4548,7 +4548,7 @@ and using ``curr`` instead of ``O`` otherwise, we get:
a. Set ``P`` to ``ToString(P)``.
b. (Arguments object special behavior.) Let ``map`` be the value of
b. (Arguments object exotic behavior.) Let ``map`` be the value of
the ``[[ParameterMap]]`` internal property of the arguments object.
c. If the result of calling the ``[[GetOwnProperty]]`` internal method
@ -4599,7 +4599,7 @@ and using ``curr`` instead of ``O`` otherwise, we get:
8. If ``O`` is a ``Function`` object or an ``arguments`` object which
contains a ``[[ParameterMap]]`` internal property:
a. (Arguments or Function object special behavior.)
a. (Arguments or Function object exotic behavior.)
If ``P`` is ``"caller"`` and ``res`` is a strict mode ``Function``
object, throw a ``TypeError`` exception.
@ -4637,7 +4637,7 @@ The property accessor coercions are the same as for ``GetValue``:
The ``PutValue()`` call is simple:
* If the base reference is primitive, it is coerced to an object, and a
special variant of ``[[Put]]`` is used.
exotic variant of ``[[Put]]`` is used.
* Otherwise, standard ``[[Put]]`` is used.
@ -4901,7 +4901,7 @@ the section on preliminary algorithm work).
Before inlining, the cases for "update old property" and "create new property"
are isolated into goto labels (as there are two places where a new property
is created). The ``[[DefineOwnProperty]]`` calls with special behaviors
is created). The ``[[DefineOwnProperty]]`` calls with exotic behaviors
inlined are then substituted. "Reject" is also made an explicit label.
The resulting algorithm is:
@ -5059,21 +5059,21 @@ Notes:
* In step 8, we don't need to check for array index updates: the property
already exists, so array ``length`` will not need an update.
* In step 8, the original ``[[DefineOwnProperty]]`` special behavior is
* In step 8, the original ``[[DefineOwnProperty]]`` exotic behavior is
split into a pre-step and a post-step because the ``"length"`` write
may fail. However, because we've inlined ``[[CanPut]]``, we know that
the write will succeed, so both the pre- and post-behaviors can be
handled in step 8 internally.
* In step 8, we don't need to check for arguments special behavior, as
* In step 8, we don't need to check for arguments exotic behavior, as
only number-like indices have magic bindings (not ``"length"``).
* In steps 12-14, we don't need to check for arguments special behavior: any
* In steps 12-14, we don't need to check for arguments exotic behavior: any
"magically bound" property must always be present in the arguments
object. If a bound property is deleted, the binding is also deleted
from the argument parameter map.
* In step 12, we don't need to check for ``length`` special behavior: the
* In step 12, we don't need to check for ``length`` exotic behavior: the
``length`` property always exists for arrays so we cannot get here with
arrays.
@ -5274,7 +5274,7 @@ Avoiding temporaries altogether:
Notes:
* Step 7: if array special behavior exists, we can return right after
* Step 7: if array exotic behavior exists, we can return right after
processing the ``length`` update; in particular, step 9 is not
necessary as an object cannot be simultaneously an array and an
arguments object.
@ -5487,7 +5487,7 @@ Implementation notes
* Property writes may fail for out of memory or other internal reasons.
In such cases the algorithm should just throw an error and avoid making
any updates to the object state. This is easy for normal properties,
but there are some subtle issues when dealing with special behaviors
but there are some subtle issues when dealing with exotic behaviors
which link multiple properties together and should be updated either
atomically or in some consistent manner. In particular:
@ -6127,7 +6127,7 @@ First draft
Starting from the original algorithm and inlining both
``ToPropertyDescriptor()`` and the ``[[DefineOwnProperty]]`` algorithm
with special behaviors, we get:
with exotic behaviors, we get:
1. If ``Type(O)`` is not ``Object`` throw a ``TypeError`` exception.

134
doc/hobject-design.txt
View File

@ -10,9 +10,9 @@ and is the most important type from an implementation point of view.
It provides objects for various purposes:
* Objects with E5 normal object semantics
* Objects with E5 array object special behavior
* Objects with E5 string object special behavior
* Objects with E5 arguments object special behavior
* Objects with E5 array object exotic behavior
* Objects with E5 string object exotic behavior
* Objects with E5 arguments object exotic behavior
* Objects with no E5 semantics, for internal use
This document discusses the ``duk_hobject`` object in detail, including:
@ -21,7 +21,7 @@ This document discusses the ``duk_hobject`` object in detail, including:
* Features of Ecmascript E5 objects
* Internal data structure and algorithms
* Enumeration guarantees
* Ecmascript property behavior (default and special)
* Ecmascript property behavior (default and exotic)
* Design notes, future work
The details of property-related algorithms in E5 are pretty intricate
@ -38,11 +38,11 @@ The following parts of Ecmascript E5 are useful background:
+-----------+-------------------------------------------------------------+
| 8.12 | Default property access methods |
+-----------+-------------------------------------------------------------+
| 10.6 | Arguments object special behavior |
| 10.6 | Arguments object exotic behavior |
+-----------+-------------------------------------------------------------+
| 15.4.5.1 | Array object special behavior |
| 15.4.5.1 | Array object exotic behavior |
+-----------+-------------------------------------------------------------+
| 15.5.5.2 | String object special behavior |
| 15.5.5.2 | String object exotic behavior |
+-----------+-------------------------------------------------------------+
See also the following documentation:
@ -916,14 +916,14 @@ Notes:
* The array part is an optimized structure for reading and writing
array indexed properties efficiently. It can be used for *any* object,
not just the Ecmascript ``Array`` object, and Ecmascript ``Array``
special behaviors are unrelated to the array part's existence.
exotic behaviors are unrelated to the array part's existence.
* A non-\ ``Array`` object with an array part does not get the ``Array``
related special behaviors (like automatic interaction between array
related exotic behaviors (like automatic interaction between array
indexed elements and the ``length`` property).
* An ``Array`` object may be created without an array part, or may have its
array part abandoned. The ``Array`` special behaviors must keep on
array part abandoned. The ``Array`` exotic behaviors must keep on
working even if the ``Array`` object has no array part.
* The ``Array`` ``length`` property is stored as an ordinary property in
@ -1600,8 +1600,8 @@ double brackets are omitted from the specification property names
+-------------------+------------------------------------------------------+
Special behavior and virtual properties
=======================================
Exotic behavior and virtual properties
======================================
Terminology
-----------
@ -1609,7 +1609,7 @@ Terminology
The E5 specification defines default property access algorithms like
``[[GetProperty]]`` and ``[[DefineOwnProperty]]`` in E5 Section 8.12.
Some objects have behavior which differs from default behavior; we call
these *special properties* (or properties with *special behavior*), as
these *exotic properties* (or properties with *exotic behavior*), as
opposed to *normal properties* (or properties with *normal behavior* or
*default behavior*).
@ -1617,7 +1617,7 @@ Conceptually each object has a number of algorithms "stored" in its
internal properties (E5 Section 8.6.2), including all the property access
algorithms. The current implementation of property access is completely
different: there are fixed algorithms for property access, which change
their behavior based on object type and flags. The special behaviors are
their behavior based on object type and flags. The exotic behaviors are
thus "inlined" into a single algorithm.
From a purely implementation viewpoint some properties are stored in a data
@ -1625,19 +1625,19 @@ structure as concrete key-value pairs, while others are computed
on-the-fly. The former are called *concrete properties* and the latter
*virtual properties*. Whether a property is concrete or virtual should
have no externally visible impact with respect to compliance.
Note that these two concepts ("being special" and "being virtual") are
indepedent: a special property can be implemented with a concrete property
Note that these two concepts ("being exotic" and "being virtual") are
indepedent: a exotic property can be implemented with a concrete property
storing its value, and a normal property can be implemented as a virtual
property.
Special behaviors in E5 specification
-------------------------------------
Exotic behaviors in E5 specification
------------------------------------
Special behaviors are discussed at least in the following places in the E5
Exotic behaviors are discussed at least in the following places in the E5
specification (page numbers refer to page numbers on the page contents, not
the "PDF page number").
Section 8.6.2, pages 32-33 summarizes special behavior and refers to:
Section 8.6.2, pages 32-33 summarizes exotic behavior and refers to:
* Array objects: ``[[DefineOwnProperty]]``, E5 Section 15.4.5.1
@ -1645,28 +1645,28 @@ Section 8.6.2, pages 32-33 summarizes special behavior and refers to:
* Arguments objects: ``[[Get]]``, ``[[GetOwnProperty]]``,
``[DefineOwnProperty]]``, ``[[Delete]]``, E5 Section 10.6
(the special behavior of a non-strict arguments object is pretty
(the exotic behavior of a non-strict arguments object is pretty
intricate and is discussed separately in ``arguments-object.txt``)
* Function objects: ``[[Get]]``, E5 Section 15.3
Special behavior for ``[[Get]]``:
Exotic behavior for ``[[Get]]``:
* The ``arguments`` object: E5 Section 10.5
+ If ``arguments.caller`` has a value, which is a strict function object,
the ``[[Get]]`` operation fails after standard lookup is complete.
+ Note that the special behavior occurs at the level of ``[[Get]]`` and
+ Note that the exotic behavior occurs at the level of ``[[Get]]`` and
is *not* visible through property descriptors, e.g. through
``[[GetProperty]]`` or ``[[GetOwnProperty]]``.
+ Special behavior only applies to non-strict arguments objects.
+ Exotic behavior only applies to non-strict arguments objects.
* The ``Function`` object: E5 Section 15.3.5.4
+ Same special behavior for ``caller`` property as for ``arguments``
+ Same exotic behavior for ``caller`` property as for ``arguments``
object.
Special behavior for ``[[GetOwnProperty]]``:
Exotic behavior for ``[[GetOwnProperty]]``:
* ``String`` object array-index properties: E5 Section 15.5.5.2
@ -1686,9 +1686,9 @@ Special behavior for ``[[GetOwnProperty]]``:
+ The ``[[Value]]`` of a property descriptor may be overridden for
"magically bound" properties (some numeric indices).
+ Special behavior only applies to non-strict arguments objects.
+ Exotic behavior only applies to non-strict arguments objects.
Special behavior for ``[[DefineOwnProperty]]``:
Exotic behavior for ``[[DefineOwnProperty]]``:
* ``Array`` ``length`` property: E5 Section 15.4.5.1
@ -1703,18 +1703,18 @@ Special behavior for ``[[DefineOwnProperty]]``:
+ Automatic interaction with "magically bound" variables (some
numeric indices). May also remove magic binding.
+ Special behavior only applies to non-strict arguments objects.
+ Exotic behavior only applies to non-strict arguments objects.
Special behavior for ``[[Delete]]``:
Exotic behavior for ``[[Delete]]``:
* The ``arguments`` object: E5 Section 10.6
+ Automatic interaction with "magically" bound variables (some
numeric indices), may remove magic binding.
+ Special behavior only applies to non-strict arguments objects.
+ Exotic behavior only applies to non-strict arguments objects.
When implementing special or virtual properties, property attributes must
be respected normally. Special or virtual properties may have specific
When implementing exotic or virtual properties, property attributes must
be respected normally. Exotic or virtual properties may have specific
initial attributes, but these are not fixed and may be changed later by
user code. The *only* properties which are "truly fixed" are:
@ -1727,10 +1727,10 @@ cannot be changed back to writable after that. This has the practical
implication that only "truly fixed" properties can be easily implemented
as stateless virtual properties.
Summary of special properties
-----------------------------
Summary of exotic properties
----------------------------
The following table summarizes special properties defined in the E5
The following table summarizes exotic properties defined in the E5
specification, along with their (initial) property attributes in the
columns W(ritable), E(numerable), and C(onfigurable):
``y`` means "true", ``n`` means "false", ``a`` means "any":
@ -1746,12 +1746,12 @@ columns W(ritable), E(numerable), and C(onfigurable):
| instance | indices | | | | ``length`` (if new index is above |
| | | | | | existing length) |
+------------+------------+---+---+---+-----------------------------------+
| ``String`` | ``length`` | n | n | n | No special behavior as such, but |
| ``String`` | ``length`` | n | n | n | No exotic behavior as such, but |
| instance | | | | | easy to implement as a virtual |
| | | | | | property because not writable |
| | | | | | or configurable. |
+------------+------------+---+---+---+-----------------------------------+
| ``String`` | array | n | y | n | No special behavior as such, but |
| ``String`` | array | n | y | n | No exotic behavior as such, but |
| instance | indices | | | | maps individual characters to |
| | inside | | | | indicates; affects enumeration. |
| | string | | | | |
@ -1781,75 +1781,75 @@ columns W(ritable), E(numerable), and C(onfigurable):
Notes:
* The special properties for ``String`` instances (which are objects) also
* The exotic properties for ``String`` instances (which are objects) also
apply in practice to plain strings, because properties of plain strings
can also be accessed (the string is automatically promoted to a temporary
object; the implementation handles this without an actual temporary object
being created).
* The ``caller`` property of a non-strict arguments object is curious: it has
special behavior but no such property is established for non-strict argument
exotic behavior but no such property is established for non-strict argument
objects. (This is why its property attributes are listed as "any" above.)
* The only special properties which are easy to implement as fully virtual,
* The only exotic properties which are easy to implement as fully virtual,
stateless properties are the ``String`` instance ``length`` and
array index properties, because they are non-configurable and non-writable.
They are enumerable, though, which must be taken into account in enumeration.
* The array ``length`` property has an initial value which is a valid array
length (32-bit unsigned integer). The special behavior of the property
length (32-bit unsigned integer). The exotic behavior of the property
ensures that whatever values are assigned to it, they are either rejected
or coerced into a valid array length (32-bit unsigned integer).
Implementation of special properties
------------------------------------
Implementation of exotic properties
-----------------------------------
The following table summarizes the implementation of special properties at
The following table summarizes the implementation of exotic properties at
the moment.
+------------+------------+-----------------------------------------------+
| Object | Property | Description |
+============+============+===============================================+
| ``Array`` | ``length`` | Stored as a concrete property. |
| instance | | ``DUK_HOBJECT_FLAG_SPECIAL_ARRAY`` enables |
| | | special behavior in: |
| instance | | ``DUK_HOBJECT_FLAG_EXOTIC_ARRAY`` enables |
| | | exotic behavior in: |
| | | ``duk_hobject_put_value()``, |
| | | ``duk_hobject_object_define_property()``. |
+------------+------------+-----------------------------------------------+
| ``Array`` | array | Stored as conrete properties in array part |
| instance | indices | or entry part (if array part abandoned). |
| | | ``DUK_HOBJECT_FLAG_SPECIAL_ARRAY`` enables |
| | | special behavior in: |
| | | ``DUK_HOBJECT_FLAG_EXOTIC_ARRAY`` enables |
| | | exotic behavior in: |
| | | ``duk_hobject_put_value()``, |
| | | ``duk_hobject_object_define_property()``. |
+------------+------------+-----------------------------------------------+
| ``String`` | ``length`` | Virtual property computed from the string |
| instance | | length of the internal ``_value`` property. |
| | | ``DUK_HOBJECT_FLAG_SPECIAL_STRINGOBJ`` enables|
| | | special behavior in: |
| | | ``DUK_HOBJECT_FLAG_EXOTIC_STRINGOBJ`` enables |
| | | exotic behavior in: |
| | | ``get_own_property_desc()``. |
+------------+------------+-----------------------------------------------+
| ``String`` | array | Virtual properties computed by looking up |
| instance | indices | characters of the internal ``_value`` |
| | inside | property. |
| | string | ``DUK_HOBJECT_FLAG_SPECIAL_STRINGOBJ`` enables|
| | length | special behavior in: |
| | string | ``DUK_HOBJECT_FLAG_EXOTIC_STRINGOBJ`` enables |
| | length | exotic behavior in: |
| | | ``get_own_property_desc()``. |
+------------+------------+-----------------------------------------------+
| plain | ``length`` | Special handling in property access code, |
| plain | ``length`` | Exotic handling in property access code, |
| string | | return string character length without |
| value | | promoting the plain string value to a |
| | | temporary ``String`` instance. |
+------------+------------+-----------------------------------------------+
| plain | array | Special handling in property access code, |
| plain | array | Exotic handling in property access code, |
| string | indices | return individual character value without |
| value | inside | promoting the plain string value to a |
| | string | temporary ``String`` instance. |
| | length | |
+------------+------------+-----------------------------------------------+
| Arguments | some | Stored as concrete property values. |
| object, | numeric | ``DUK_HOBJECT_FLAG_SPECIAL_ARGUMENTS`` enables|
| non-strict | indices | special behavior in: |
| object, | numeric | ``DUK_HOBJECT_FLAG_EXOTIC_ARGUMENTS`` enables |
| non-strict | indices | exotic behavior in: |
| | | ``get_own_property_desc()``, |
| | | ``duk_hobject_get_value()``, |
| | | ``duk_hobject_put_value()``, |
@ -1857,10 +1857,10 @@ the moment.
| | | ``duk_hobject_object_define_property()``. |
+------------+------------+-----------------------------------------------+
| Arguments | ``caller`` | Stored as a concrete property. |
| object, | | ``DUK_HOBJECT_FLAG_SPECIAL_ARGUMENTS`` enables|
| non-strict | | special behavior in: |
| object, | | ``DUK_HOBJECT_FLAG_EXOTIC_ARGUMENTS`` enables |
| non-strict | | exotic behavior in: |
| | | ``duk_hobject_get_value()``. |
| | | This special behavior only affects |
| | | This exotic behavior only affects |
| | | ``[[Get]]``, it is not visible through e.g. |
| | | property descriptors or |
| | | ``[[GetOwnProperty]]``. |
@ -1873,16 +1873,16 @@ Notes:
because they are non-configurable and non-writable. However, they *are*
enumerable which affects enumeration handling.
* If array ``length`` becomes non-writable, the special behavior ensures
* If array ``length`` becomes non-writable, the exotic behavior ensures
no elements above the specified length can ever be inserted. The array
part could thus be compacted without risk of it being extended afterwards.
Notes on array length and array indices
---------------------------------------
The special array semantics only apply to valid array indices. Nothing
The exotic array semantics only apply to valid array indices. Nothing
prevents user code from writing to numeric array indices higher than the
maximum valid array index, but such writes will get no special behavior::
maximum valid array index, but such writes will get no exotic behavior::
var x = [];
x["4294967294"] = 1; // has array semantics, updates length
@ -2260,7 +2260,7 @@ There used to be a separate object type for internal objects.
The differences to standard objects include: no need to support
array part, no property attributes, no accessor properties,
no need to preserve property ordering, no special behaviors, etc.
no need to preserve property ordering, no exotic behaviors, etc.
However, the extra cost of having another object data structure
does not seem worth it. The effects are:
@ -2361,7 +2361,7 @@ in practice. Their prototype chain is::
|
Array instance (see E5 Section 15.4.2)
The special flag based approach would work if the object and array prototypes
The exotic flag based approach would work if the object and array prototypes
have no array indexed keys.
Existing Ecmascript implementations do not seem to implement the
@ -2472,10 +2472,10 @@ three basic approaches to manage these:
The current approach is to create a snapshot of keys and then re-check them
to see whether they've been deleted during enumeration.
More modular virtual/special properties
More modular virtual/exotic properties
---------------------------------------
More modular (but still compact) way of implementing virtual and special
More modular (but still compact) way of implementing virtual and exotic
properties?
Test cases

4
doc/hobject-enumeration.txt
View File

@ -265,8 +265,8 @@ Test 3 shows that even though the object itself is forced to be of
length 2, prototype enumeration still lists all keys of the prototype,
including "2" which is beyond the array length.
Test 4 shows that 'length' is not special for an object which has an
array as a prototype. Special semantics of 'length' do not apply to
Test 4 shows that 'length' is not exotic for an object which has an
array as a prototype. Exotic semantics of 'length' do not apply to
the object because the property write goes to the object, which is not
an array. This also explains the result of test 3.

Write Preview
Loading…
Cancel
Save