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