Interfaces marked as @JsFunction have property length set to 0 #9675

Activity

1. vasvir

   added a commit that references this issue on Dec 2, 2019

   Fixes issue gwtproject#9675. This patch supports up to 10 arguments a…

   ...

   decf697
2. vasvir commented on Jan 14, 2020

   

   vasvir

   on Jan 14, 2020

   Last edited by vasvir

   Author

   More actions

   There is a fiddle with a bit more experimentation and benchmarks at https://jsfiddle.net/vasvir/forwtzqd/

   • makeLambdaFunction0 is the original method used in the GWT project
   • makeLambdaFunction1 is the method (hardwired switch statement) that is implemented in the submitted patch decf697. It is based on https://stackoverflow.com/questions/7316688/how-to-programmatically-set-the-length-of-a-function and it has the same speed as the original code.
   • makeLambdaFunction2 is a fully generic, argument count agnostic, based on eval, implementation. It is based on https://stackoverflow.com/questions/51953812/is-it-possible-to-change-a-lexical-scope-programmatically-in-javascript and it is around 600 times slower than the original code.
   • makeLambdaFunction3 is an improvement of makeLambdaFunction2. It eliminates one eval function out of two and reduces the overhead to 300 times compared to the original code. Still however it is not considered for patch submission.

   The current patch implements a hardwired switch statement with 10 branches. So an argument count of up to10 is supported with this implementation. If the function has more than 10 arguments then the argument count is set to 10.

   In the original implementation the argument count of the functions was set to 0 disregarding the actual input arguments. The patch does not prevent to create lambda with > 10 arguments. It just corrects the argument count (function.length) in the cases <= 10.

   If the need arises in the future to support argument counts > 10 the required extension of the function is trivial and straightforward.
3. rluble commented on Jan 14, 2020

   

   rluble

   on Jan 14, 2020

   Contributor

   More actions

   For browser with es6 support I believe that makeLambdaFunction could be written as

   function makeLambdaFunction(samMethod, ctor, ctorArguments) {
     var lambda = function(...args) {
       return samMethod.apply(lambda, args);
     }
     ctor.apply(lambda, ctorArguments);
     return lambda;
   }

   but that would not fix the issue, since now probably the length would be always 1. GWT could also generate the makeLambdaFunction code for each lambda with the declared number of parameters but that would introduce an unnecessary codesize cost.

   In any case deciding what to do based on the declared argument count is a poor practice IMHO. The simplest work around would be to have wrapper functions to be used with the particular libraries, e.g.

   function asComparator(fn) {
     return function(a, b) { return fn(a,b); };
   }
   
   function asAccessor(fn) {
     return function(a) { return fn(a); };
   }
4. vasvir commented on Jan 15, 2020

   

   vasvir

   on Jan 15, 2020

   Author

   More actions

   The workaround you suggest is valid and this what I have done in my D3 bindings.

   When I said there are no workarounds I was talking about setting correctly the function.length in the generated lambda.

   Furthermore I agree that I don't like the API that accepts two different callbacks (accessor and comparator) in one method that checks arguments count.

   But...

   • The unfolding of this bug/issue took me some hours. I am certain that other people trying to write jsinterop will be bitten also in the future.
   • Splitting the interface with wrappers is natural for Java but unnatural for Js. It involves creating a @JsOverlay method that has 2 different signatures in order to invoke the wrappers. Not sure if it can be done without JSNI. I think that introduces friction between Js libraries and Java jsinterop bindings.