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 <[email protected]> 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
