Dynalink and delete

Sundararajan Athijegannathan sundararajan.athijegannathan at oracle.com
Wed May 25 04:36:40 UTC 2016


There is a not-so-pretty workaround though. Nashorn routes delete on
jdk.nashorn.api.scripting.JSObject instances to removeMember method.

If you can wrap your Java objects as JSObjects [ may be just for
delete], then you can customize delete on your objects.

var myJavaObj = .... ; // myJavaObj is an instance of MyJavaObject
linked by pluggable Dynalink linker MyJavaObjectLinker

myJavaObj.foo = "hello"; // set property handled by MyJavaObjectLinker

delete jsObj(myJavaObj).foo;  // jsObj is a function returns a JSObject
wrapper of myJavaObj. The JSObject wrapper can override removeMember.

// or a special property on myJavaObj to return a JSObject wrapper

delete myJavaObj._.foo; // "_" property returns a JSObject wrapper on
myJavaObject which then takes care of "delete"

-Sundar

On 5/25/2016 9:50 AM, Sundararajan Athijegannathan wrote:
> I recall that we did discuss about the StandardOperation set. "delete"
> and "iterator" were discussed at one point.  But, languages are very
> different and difficult to generalize to include all operations. For eg.
> Python's del does not return boolean, ECMAScript delete returns boolean
> and sometime throws TypeError (strict mode)!
>
> Hence dynalink has Operation as interface and StandardOperation as one
> implementation.   In the hindsight, it *may* be desirable to include
> delete. But, it is too late for jdk9 to update dynalink API :(
>
> Best,
>
> -Sundar
>
>
> On 5/24/2016 3:41 AM, Marc Downie wrote:
>> Dear all,
>>
>> First of all, many thanks for this year's JEP-276 / jdk.dynalink
>> refactoring. We've been enjoying all of the benefits of installing a custom
>> Linker without having to maintain a fork of Nashorn just to get it
>> installed. We can massage and customize the face that Java objects present
>> to JavaScript almost completely.
>>
>> The one thing that remains that I can't manipulate is the behavior of Java
>> objects with respect to *delete*. In short we have elaborately customizable
>> *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other
>> languages and runtimes, but no *dyn:deleteX. *Is this by omission or by
>> design?
>>
>> best,
>>
>> Marc



More information about the nashorn-dev mailing list