Hi Antonio, This has now been implemented. If a method with the matching name is found, the resulting exception will be an EolIllegalOperationParametersException with the following message: Invalid number [or types] of arguments for operation 'orElseGet': expected 'java.util.function.IntSupplier' but got: 'org.eclipse.epsilon.eol.dom.PropertyCallExpression' which I hope is more useful than the more generic EolIllegalOperationException. Thanks, Sina Hi Sina, Yes, I think that would be helpful and reduce the number of queries in the Epsilon forum ;-). Hi Antonio, I’m still trying to understand the problem. If the user does something like: Native("java.util.stream.IntStream") .range(1, 10) .findFirst() .orElseGet(a | a.someProp); it is obviously invalid since orElseGet expects a Supplier not a Function. In the above case, an EolRuntimeException is thrown which wraps the original error message – in this case, “Method 'orElseGet' not found for: OptionalInt[1]”. The Epsilon and Java stack trace are both reported as usual. So I guess the issue is that the user should be told that the reason “orElseGet” was not found is not due to a spelling mistake, but because the lambda _expression_ did not match the expected signature? If so, then would it be sufficient to add the expected signature to the error message as well as stating that the issue is due to incorrect parameters? Thanks, Sina Hi Sina, I am thinking more in terms of error reporting - if we try to invoke a functional interface with the wrong argument types, what is the user going to see? If you check that the argument value is assignable to the argument type (basically, Class.isInstanceOf), and that doesn't work, then you can clearly report the situation to the user. Otherwise, you will get a very strange exception and we will have more threads to answer in the forum :-P. (As you may remember from the parallelisation branch, I take more of a "let's-not-explode-the-user's-brain" angle here... :-D) Hi Antonio, Thank you for your feedback. However I’m not sure what you mean by checking the types of parameters. I can’t really envision a scenario where the parameter could be “wrong”, because it’s just a variable used in the lambda just like all first-order operations, so it’s typed “automatically” based on the operation being called. However the return type is not checked and assumed to be correct, but then this is the case for all Epsilon languages anyway in the absence of static analysis. Perhaps what you mean is that if there are multiple methods with the same name and same number of parameters then there is ambiguity in which one is called? In that case I can see the value in type-checking. However I don’t know of any functional interfaces which have the same name, same number of parameters but different parameter types. I also don’t see how we could resolve this ambiguity should it arise even with static analysis. If you have any solutions in mind please let me know. Thanks, Sina Hi Sina, Thanks for your work on this! Just one thing: I see that we check the number of arguments and that we seem to use proxy instances for the various parameter values, but I don't see any check on the actual types. Shouldn't we check the types of the parameters as well? I suppose you are taking advantage of the fact that functional interfaces in Java should really only have one method, but at least we could complain when somebody tries to pass the wrong type to the functional interface. Hi all, In the “lambda-support” branch, I have fixed Bug 464793 [1] by changing the manifest of org.eclipse.epsilon.dependencies to depend on org.antlr.runtime version 3.2.0. Furthermore, I have also added capabilities to use first-order operation call _expression_ syntax to invoke functional interfaces on native types. Examples of this can be found in org.eclipse.epsilon.eol.engine.test.acceptance.firstOrder.lambda.LambdaExpressionTest.eol, which demonstrates the use Functions, Predicates, BiFunctions, Suppliers and Consumers. I managed to get around modifying the EOL grammar to support Suppliers by using the underscore to signify a non-parameter. This will only affect lambda expressions on native types, not existing first-order operation expressions. For anyone interested in the implementation, please see org.eclipse.epsilon.eol.execute.operations.DynamicOperation and org.eclipse.epsilon.eol.dom.FeatureCallExpression#getAbstractOperation. If there are no objections or suggestions, I propose to merge these changes into the main branch and also document this on the website and/or Epsilon book. Thanks, Sina [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=464793 _______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
-- Antonio Garcia-Dominguez _______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
-- Antonio Garcia-Dominguez _______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/epsilon-dev
-- Antonio Garcia-Dominguez |
