BeansLinker has a bunch of static methods like getReadableInstancePropertyNames
etc. that could be used to implement special cases in ScriptRuntime.IN. A logic
modelled after how NativeObject.bindProperties works should do (after all, “in”
on a bean should work equivalently to how it works on the result of
Object.bindProperties({}, bean).
To answer your operator question, a lot of INVOKESTATIC calls to RuntimeNode
special methods could be eqiuvalently reworked to use INVOKEDYNAMIC with custom
operations, although the benefit is unclear as long as all possible
implementations reside within a single runtime (Nashorn). Expanding the set of
standard operations would probably make more sense… My first candidate for a
new standard operation is specifically DELETE (folks have asked for it here on
the list), I just couldn’t find the time to make it happen for the JDK 9
initial release timeframe :-(
Attila.
> On 26 Jan 2017, at 13:57, Hannes Wallnöfer <hannes.wallnoe...@oracle.com>
> wrote:
>
> I noticed today that we don’t support the „in“ operator on JavaBeans.
> ScriptRuntime.IN(Object, Object) returns false if the second argument is a
> generic object (not a ScriptObject or JSObject).
>
> I was wondering if this is an oversight or intentional. If it is the former,
> how would we implement this? Is this the case for a non-standard Dynalink
> operation such as HAS?
>
> Hannes
