David-Sarah Hopwood wrote:
> Maciej Stachowiak wrote:
>> On Nov 14, 2008, at 4:48 PM, David-Sarah Hopwood wrote:
>>> David-Sarah Hopwood wrote:
>>>> Caveat:
>>>> [section 15]
>>>> # The value of the [[Class]] property of a host object may be any value,
>>>> # even a value used by a built-in object for its [[Class]] property.
>>>>
>>>> So any random host object might have [[Class]] "Function" (which is a
>>>> bug). If that is the case, all bets are off (and in that case steps 11
>>>> and 15 of the 'bind' algorithm are broken anyway -- for example, the
>>>> 'length' or 'prototype' properties of G might not exist).
>>> We didn't resolve this.
> 
> We still didn't resolve this.
> 
> If it is not fixed by requiring host objects not to have [[Class]]
> "Function", then the bind algorithm must be fixed in some other way.
> So must all of the other bugs in ES3 that result from assumptions
> about objects with [[Class]] "Date" or "RegExp" having all of the
> properties and behaviour of those types, in sections 15.5.4.{10,11,12,14},
> and in the specifications of Date and RegExp methods.

For example:

# 15.5.4.14 String.prototype.split (separator, limit)
#
# [...] The value of separator may be a string of any length or it may
# be a RegExp object (i.e., an object whose [[Class]] property is "RegExp";
# see 15.10).
#
# [...]
# 6. If separator is a RegExp object (its [[Class]] is "RegExp"), let
#    R = separator; otherwise let R = ToString(separator).

The assumption that 'a RegExp object' means the same thing as 'an object
whose [[Class]] is "RegExp"' is strictly speaking incorrect, but that is
clearly what is assumed.

-- 
David-Sarah Hopwood