Subj : Re: Rhino E4X bug or feature?
To   : netscape.public.mozilla.jseng
From : Brendan Eich
Date : Thu Jul 21 2005 06:17 pm

Brendan Eich wrote:
> Olinda Spider wrote:
> 
>> In other words, right now the parser recognizes the difference between
>> accessing an object's property and accessing an object's method.  Given
>> the following two statements:
>>
>>   var num = object.length()
>>   var element = object.length
>>
>> The parser generates different opcodes for accessing each of the
>> "length" items.  Is there a reason the same parsing process can not be
>> applied to the following two statements?
>>
>>   var num = length()
>>   var element = length
> 
> 
> 
> Indeed that could be done, but ECMA-357 must fully specify what happens 
> here, and it fails to do so. 


I meant to write: "ECMA-357 must fully specify what you want to happen 
here, and it fails to do so."  ECMA-357, as I went on to say, does fully 
specify what Rhino and SpiderMonkey do.  Too bad it's a usability bug.

/be


  11.2.2 step 1 evaluates MemberExpression
> in this production:
> 
>   CallExpression: MemberExpression Arguments
> 
> without providing any parametric hint that a different kind of 
> [[HasProperty]] from the one in ECMA-262 Edition 3, 10.1.4 step 2, 
> should be used.  But ECMA-357 does specify [[HasProperty]] for XML 
> objects (ECMA-357, 9.1.1.6) in a way that excludes the XML methods 
> defined on XML.prototype.  So there is no way to find an XML method by 
> scope resolution of its unqualified identifier.
> 
> Rhino and SpiderMonkey follow the spec.  The spec has the bug here.
> 
> /be

.