Am 26.01.2017 um 15:08 schrieb Attila Szegedi <szege...@gmail.com>:
>
> 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).
Thanks for that suggestion. I had skimmed over the static BeansLinker methods
but had overseen that particular method, so it might be easier to implement
than I had thought.
> 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 :-(
Yes, I know DELETE has been a candidate for a long time. Actually, HAS/CONTAINS
and DELETE would make a nice pair as they’d complement our coverage for basic
collection (map/set) functionality. It’s definitely too late for the initial
JDK 9 release, but it could be a nice addition for 10.
Hannes
> 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
>
