Supporting [[hasProperty]] on JavaBeans
Hannes Wallnöfer
hannes.wallnoefer at oracle.com
Fri Jan 27 09:50:39 UTC 2017
Am 26.01.2017 um 15:08 schrieb Attila Szegedi <szegedia at 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.wallnoefer at 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
>
More information about the nashorn-dev
mailing list