__noSuchProperty__ poll

[A. Sundararajan]

Other issue is __noSuchMethod__ - which is called for

     obj.foo();

what about

     obj[prop]();  ?

Here obj[prop] step is done first and then the resulting function is 
invoked. So, should we have call __noSuchProperty__ or __noSuchMethod__ ?

-Sundar

On Tuesday 09 April 2013 02:44 AM, Hannes Wallnoefer wrote:
> I'm with Marcus: It would be preferable to have consistent behaviour, 
> but not if there's a noticeable performance penalty.
>
> Hannes
>
> Am 2013-04-08 20:27, schrieb Marcus Lagergren:
>> I think consistency makes sense, but there might be potential 
>> performance implications for modifying the index access. These should 
>> probably be investigated.
>>
>> On Apr 8, 2013, at 7:30 PM, Jim Laskey <jlaskey at me.com> wrote:
>>
>>> In Nashorn, we introduced __noSuchProperty__ as a means of 
>>> overriding property search when a property is not declared. Example;
>>>
>>> jjs> var other = { a: 10, b: 20, c: 30 };
>>> jjs> var obj = { delegate: other, __noSuchProperty__: function(name) 
>>> { return this.delegate[name]; } }
>>> jjs> obj.b;
>>> 20
>>>
>>> In the current version of Nashorn, we don't call the 
>>> __noSuchProperty__ handler when accessed using indexing. However, 
>>> the question has come up as whether this support should extend to 
>>> indexing as well; providing symmetry between property access and 
>>> indexing.  Thus continuing the example;
>>>
>>> jjs> obj["b"];
>>> 20
>>>
>>> Does this make sense to everyone?
>>>
>>> The only argument I could come up against was using indexing for 
>>> property testing, as in;
>>>
>>> jjs> if (obj["b"]) print(obj.b);
>>> 20
>>>
>>> But that argument doesn't hold since there are alternatives;
>>>
>>> jjs> obj.hasProperty("b");
>>> false
>>>
>>> or;
>>>
>>> jjs> "b" in obj;
>>> false
>>>
>>> The reason I ask is that we have a bug where megamorphic call sites 
>>> switch to indexed access (to reduce the number of cases) and thus 
>>> __noSuchProperty__ is not invoked when it should.
>>>
>>> If we change the behaviour, then we will provide symmetry and 
>>> address the bug.
>>>
>>> Comments?
>>>
>>> -- Jim
>>>
>