__noSuchProperty__ poll
Marcus Lagergren
marcus.lagergren at oracle.com
Mon Apr 8 11:27:50 PDT 2013
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
>
More information about the nashorn-dev
mailing list