[whatwg] HTML 5 : Misconceptions Documented

(put back on list, forgot to reply-all)


On Thu, Aug 7, 2008 at 2:16 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:
>
>> On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
>>>
>>>> On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
>>>>>
>>
>>
>>>>> I think Web IDL should provide a formalism to cater to this, because
>>>>> nearly
>>>>> all bindings with special dynamic properties work like this afaik. But
>>>>> I
>>>>> think it would have to involve a pseudo-method for the "hasOwnProperty"
>>>>> check (which "in" is based on).
>>>>
>>>> hasOwnProperty is ECMAScript-specific.
>>>
>>
>> Yes it is.
>>
>>> The Web IDL includes specific requirements for how to map an interface
>>> specified in Web IDL to ECMAScript. So, indeed, that would be the part of
>>> the Web IDL spec that would be the best place to define this.
>>>
>>
>> Since Maciej is probably considered to be an EcmaScript expert and I
>> am not, and since he had stated that 'in' calls 'hasOwnProperty', and
>> even continued to argue the claim, it is necessary and appropriate to
>> demonstrate proof that the 'in' does not call 'hasOwnProperty'.
>>
>> The following example shows that no implementation calls
>> hasOwnProperty with use of 'in' operator.
>
> The more accurate way to put it would be that the 'in' operator performs the
> same check at ever item in the prototype chain (including the original
> object) that the original value of hasOwnProperty performs on only the
> object itself. You are correct that replacing hasOwnProperty either on an
> object or in its prototype chain will have no effect on operation of the
> 'in' operator.
>

What you're sort of describing is called [[HasProperty]] in the
specification. In terms of the specification, it is not related to
hasOwnProperty.

[[HasProperty]] is internal and works differently.

| 8.6.2.4 [[HasProperty]](P)
|
| When the [[HasProperty]] method of O is called with property name P,
| the following steps are taken:
| 1. If O has a property with name P, return true.
| 2. If the [[Prototype]] of O is null, return false.
| 3. Call the [[HasProperty]] method of [[Prototype]] with property
| name P.
| 4. Return Result(3).

 [[HasProperty]](P) doesn't call ToString(P). [[HasFeature]] an
internal mechanism.

hasOwnProperty is not internal; it's part of Object.prototype:

| 15.2.4.5  Object.prototype.hasOwnProperty(V)\
|
| When the hasOwnProperty method is called with argument V, the
| following steps are taken:
|
| 1. Let O be this object.
| 2. Call ToString(V)
| 3. If O doesn't have a property with the name given by Result(2),
| return false.
| 4. Return true.
|
| NOTE Unlike [[HasProperty]] (8.6.2.4), this method does not consider
| objects in the prototype chain.


>> 'hasOwnProperty' is EcmaScript specific. Whether or not ordinally
>> indexed properties should be 'own' properties is not a place for IDL
>> to decide.
>
> It is just as relevant to specify whether a property is an own property as
> it is to specify whether it is visible to the 'in' operator. Both are edge
> cases that may affect interoperability but likely won't (since most authors
> will just get the property, and not check for presence). Visibility to the
> 'in' operator seems to observable difference on which you base your
> distinction between 'having a getter' and 'having a real property'.
>

Why should IDL include discussion of the prototype chain?
How can you define the prototype chain for other languages?
How can you declare properties on an object where the property name is
not a valid identifier?

There is no prototype chain in Java. The closest thing would be static
class variables. That still doesn't get around the problem of having
properties with the name '0', '1', et c. Those are not valid
identifiers in Java

namedNodeMap.0

Would not compile.

You can't have invalid identifiers in Java.

The alternative would be to not pretend or try to force other
languages to behave like EcmaScript, but to recognize EcmaScript for
what it is and allow that behavior in that binding; allow property
access using [], as it is implemented in browsers. This would require
nothing more than a simple explanation in the binding.

Garrett

> Regards,
> Maciej
>
>

Received on Thursday, 7 August 2008 15:46:04 UTC