-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider subtyping Function
#37
Comments
While I am not a friend of dispatching on Base.Callable I can see that it might be pragmatic to do so. I am open to such a PR. One hassle is that we don t want the default printing of functions. Is there more baggage we inherit from subtyping function? |
Hmm, it's never really given me baggage before - but yeah good point about the printing. |
FWIW I think the main downside of subtyping IMHO an API that dispatches on |
Really? That's weird.
You're probably right on that one. |
I was referring to this issue JuliaLang/julia#33978 |
I see - I can think of it working like When I opened this issue I didn't see any possible downsides but it's more complex than I imagined, so I'll close this one. |
Does this behavior differ depending on whether the passed callable is a |
Types also get deoptimized unless you do |
Hi,
One thing that can help with compatibility elsewhere is to hint your lenses and so-on are functions, by directly subtyping
Function
.For example the code at https://github.com/JuliaObjects/Accessors.jl/blob/master/src/optics.jl#L345 could become:
This came up in SplitApplyCombine, which (unfortunately) is currently using
Base.Callable
in a few cases (although I wish the API were factored so it were obvious which terms must be functions rather than collections), here.CC @aplavin
The text was updated successfully, but these errors were encountered: