Discussion:
Dynalink and delete
Marc Downie
2016-05-23 22:11:52 UTC
Permalink
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
Sundararajan Athijegannathan
2016-05-25 04:20:31 UTC
Permalink
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
Post by Marc Downie
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
Sundararajan Athijegannathan
2016-05-25 04:36:40 UTC
Permalink
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
Post by Sundararajan Athijegannathan
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
Post by Marc Downie
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
Attila Szegedi
2017-12-21 20:59:01 UTC
Permalink
Hi Marc,

So… this took about a year and a half to happen, but I’m happy to announce that there’s now a REMOVE operation in Dynalink. The latest EA of JDK10 contains it: <http://download.java.net/java/jdk10/docs/api/jdk/dynalink/StandardOperation.html#REMOVE <http://download.java.net/java/jdk10/docs/api/jdk/dynalink/StandardOperation.html#REMOVE>>. Hopefully you can still find a use for it :-)

What the latest EA doesn’t contain _yet_ is Nashorn using it to implement its delete operator, so even if you link REMOVE in your language runtime, Nashorn won’t be able to delete your object’s properties, and your language won’t be able to delete Nashorn JS objects’ properties yet. The good news is that this functionality is also implemented and committed, but I just committed it now, so it will only ship with the next EA build. Alternatively, if you build your own jdk10 from the tip of the jdk/jdk10 repository, or your own jdk11 from the tip of jdk/jdk, you should have it.

Best Regards,
Attila.
Post by Marc Downie
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
Marc Downie
2017-12-21 23:16:15 UTC
Permalink
Attila,

Followed the reviews and commits with anticipation, pulling the changes and
building this evening. Assuming it all goes well, I'll have it in front of
students writing code in two weeks time.

Many thanks!

Marc.
Post by Attila Szegedi
Hi Marc,
So… this took about a year and a half to happen, but I’m happy to announce
that there’s now a REMOVE operation in Dynalink. The latest EA of JDK10
contains it: <http://download.java.net/java/jdk10/docs/api/jdk/
dynalink/StandardOperation.html#REMOVE>. Hopefully you can still find a
use for it :-)
What the latest EA doesn’t contain _yet_ is Nashorn using it to implement
its delete operator, so even if you link REMOVE in your language runtime,
Nashorn won’t be able to delete your object’s properties, and your language
won’t be able to delete Nashorn JS objects’ properties yet. The good news
is that this functionality is also implemented and committed, but I just
committed it now, so it will only ship with the next EA build.
Alternatively, if you build your own jdk10 from the tip of the jdk/jdk10
repository, or your own jdk11 from the tip of jdk/jdk, you should have it.
Best Regards,
Attila.
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
Attila Szegedi
2017-12-28 18:39:16 UTC
Permalink
I’d love to learn more about how you are using Nashorn and Dynalink for teaching, if you can spare a time for a short write-up.

Thanks,
Attila.
Post by Marc Downie
Attila,
Followed the reviews and commits with anticipation, pulling the changes and building this evening. Assuming it all goes well, I'll have it in front of students writing code in two weeks time.
Many thanks!
Marc.
Hi Marc,
So… this took about a year and a half to happen, but I’m happy to announce that there’s now a REMOVE operation in Dynalink. The latest EA of JDK10 contains it: <http://download.java.net/java/jdk10/docs/api/jdk/dynalink/StandardOperation.html#REMOVE <http://download.java.net/java/jdk10/docs/api/jdk/dynalink/StandardOperation.html#REMOVE>>. Hopefully you can still find a use for it :-)
What the latest EA doesn’t contain _yet_ is Nashorn using it to implement its delete operator, so even if you link REMOVE in your language runtime, Nashorn won’t be able to delete your object’s properties, and your language won’t be able to delete Nashorn JS objects’ properties yet. The good news is that this functionality is also implemented and committed, but I just committed it now, so it will only ship with the next EA build. Alternatively, if you build your own jdk10 from the tip of the jdk/jdk10 repository, or your own jdk11 from the tip of jdk/jdk, you should have it.
Best Regards,
Attila.
Post by Marc Downie
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
Loading...