On Nov 20, 2008, at 1:39 AM, David-Sarah Hopwood wrote:
Maciej Stachowiak wrote:
[...]
But internal functions by that
definition are native Function objects, so they are not relevant to
the argument about host objects. They only differ from non-internal
Function objects by having a [[Call]] method that executes non-ECMAScript
code, and by being excluded from the discussion of Execution Contexts in
chapter 10.
If all non-ECMAScript-coded methods in the DOM, or other add-on
interfaces, can be Native internal functions rather than Host objects,
even if they have behavior that does not match any predefined native
Function, [...]
No, if they are native functions then they must match the behaviour of
a function that could have been coded in ECMAScript.
'parseInt', for example, could be coded in pure ECMAScript.
'Math.random' could be coded in ECMAScript if it communicated with a
host object in order to obtain an initial source of entropy.
Host objects, on the other hand, can have almost arbitrary behaviour,
essentially constrained only be the type signatures in the table of
section 8.6.2. That section says:
For native objects the [[Get]], [[Put]], [[CanPut]], [[HasProperty]],
[[Delete]] and [[DefaultValue]] methods behave as described in
described in 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.6.2.4, 8.6.2.5 and 8.6.2.6,
respectively, except that Array objects have a slightly different
implementation of the [[Put]] method (see 15.4.5.1). Host objects may
implement these methods in any manner unless specified otherwise; for
example, one possibility is that [[Get]] and [[Put]] for a particular
host object indeed fetch and store property values but [[HasProperty]]
always generates false.
The first sentence here also constrains internal function objects.
then I am not sure what a requirement for Host objects not to
have [[Class]] "Function" would achieve.
For functions, this requirement only simplifies the specification of
the 'bind' method slightly. The more significant problems are with
RegExp and Date -- those sections pervasively assume that anything
with [[Class]] "RegExp" behaves like a native RegExp object, and that
anything with [[Class]] "Date" behaves like a native Date object.
Maciej Stachowiak wrote:
> On Nov 20, 2008, at 1:39 AM, David-Sarah Hopwood wrote:
>> Maciej Stachowiak wrote:
[...]
>> But internal functions by that
>> definition are native Function objects, so they are not relevant to
>> the argument about host objects. They only differ from non-internal
>> Function objects by having a [[Call]] method that executes non-ECMAScript
>> code, and by being excluded from the discussion of Execution Contexts in
>> chapter 10.
>
> If all non-ECMAScript-coded methods in the DOM, or other add-on
> interfaces, can be Native internal functions rather than Host objects,
> even if they have behavior that does not match any predefined native
> Function, [...]
No, if they are native functions then they must match the behaviour of
a function that could have been coded in ECMAScript.
'parseInt', for example, could be coded in pure ECMAScript.
'Math.random' could be coded in ECMAScript if it communicated with a
host object in order to obtain an initial source of entropy.
Host objects, on the other hand, can have almost arbitrary behaviour,
essentially constrained only be the type signatures in the table of
section 8.6.2. That section says:
# For native objects the [[Get]], [[Put]], [[CanPut]], [[HasProperty]],
# [[Delete]] and [[DefaultValue]] methods behave as described in
# described in 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.6.2.4, 8.6.2.5 and 8.6.2.6,
# respectively, except that Array objects have a slightly different
# implementation of the [[Put]] method (see 15.4.5.1). Host objects may
# implement these methods in any manner unless specified otherwise; for
# example, one possibility is that [[Get]] and [[Put]] for a particular
# host object indeed fetch and store property values but [[HasProperty]]
# always generates false.
The first sentence here also constrains internal function objects.
> then I am not sure what a requirement for Host objects not to
> have [[Class]] "Function" would achieve.
For functions, this requirement only simplifies the specification of
the 'bind' method slightly. The more significant problems are with
RegExp and Date -- those sections pervasively assume that anything
with [[Class]] "RegExp" behaves like a native RegExp object, and that
anything with [[Class]] "Date" behaves like a native Date object.
--
David-Sarah Hopwood
Maciej Stachowiak wrote:
No, if they are native functions then they must match the behaviour of a function that could have been coded in ECMAScript.
'parseInt', for example, could be coded in pure ECMAScript. 'Math.random' could be coded in ECMAScript if it communicated with a host object in order to obtain an initial source of entropy.
Host objects, on the other hand, can have almost arbitrary behaviour, essentially constrained only be the type signatures in the table of section 8.6.2. That section says:
For native objects the [[Get]], [[Put]], [[CanPut]], [[HasProperty]],
[[Delete]] and [[DefaultValue]] methods behave as described in
described in 8.6.2.1, 8.6.2.2, 8.6.2.3, 8.6.2.4, 8.6.2.5 and 8.6.2.6,
respectively, except that Array objects have a slightly different
implementation of the [[Put]] method (see 15.4.5.1). Host objects may
implement these methods in any manner unless specified otherwise; for
example, one possibility is that [[Get]] and [[Put]] for a particular
host object indeed fetch and store property values but [[HasProperty]]
always generates false.
The first sentence here also constrains internal function objects.
For functions, this requirement only simplifies the specification of the 'bind' method slightly. The more significant problems are with RegExp and Date -- those sections pervasively assume that anything with [[Class]] "RegExp" behaves like a native RegExp object, and that anything with [[Class]] "Date" behaves like a native Date object.