You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 28, 2022. It is now read-only.
We can't currently fully use the function reference literal notation or the Predefined::fun function on an overloaded function. This feature is only usable if the overloaded version don't have the same number of parameters, regardless of the type.
For instance, the given code:
let f = ^java.lang.Character::toLowerCase
raises a org.eclipse.golo.runtime.AmbiguousFunctionReferenceException, since two versions exists: with a char argument and with an int one.
This limits some functional style programming aspects (e.g. HOF, point-free, etc.)
The current workaround is to use a lambda |c| -> java.lang.Character.toLowerCase(c), since in that case, the resolution is done at call time using the actual arguments. A macro could be used to create such lambda directly, but it has several drawbacks:
more verbose to use,
introduce overhead if not needed, and thus shouldn't be applied systematically,
fixes the arity (this could be fixed by using a polyadic lambda with a test on the actual number or arguments, but become ambiguous when the referenced function itself is polyadic).
The idea, as suggested by @artpej in #326 (comment), is to use a proxy object for ambiguous method references, allowing to resolve at call time.
Such object can include an inline cache and be replaced at the call site by the real reference when known.
This would also allow more polymorphic behaviour, since with could dispatch on function with different arities.
It may be a step toward lisp-like multimethods 😉
We can't currently fully use the function reference literal notation or the
Predefined::fun
function on an overloaded function. This feature is only usable if the overloaded version don't have the same number of parameters, regardless of the type.For instance, the given code:
raises a
org.eclipse.golo.runtime.AmbiguousFunctionReferenceException
, since two versions exists: with achar
argument and with anint
one.This limits some functional style programming aspects (e.g. HOF, point-free, etc.)
The current workaround is to use a lambda
|c| -> java.lang.Character.toLowerCase(c)
, since in that case, the resolution is done at call time using the actual arguments. A macro could be used to create such lambda directly, but it has several drawbacks:The idea, as suggested by @artpej in #326 (comment), is to use a proxy object for ambiguous method references, allowing to resolve at call time.
Such object can include an inline cache and be replaced at the call site by the real reference when known.
This would also allow more polymorphic behaviour, since with could dispatch on function with different arities.
It may be a step toward lisp-like multimethods 😉
See also #326, #341
The text was updated successfully, but these errors were encountered: