-
Notifications
You must be signed in to change notification settings - Fork 7
[WIP] Add dynamic callable and member lookup #27
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
base: main
Are you sure you want to change the base?
[WIP] Add dynamic callable and member lookup #27
Conversation
Codecov Report
@@ Coverage Diff @@
## master #27 +/- ##
==========================================
- Coverage 97.85% 96.84% -1.02%
==========================================
Files 25 25
Lines 1775 1805 +30
==========================================
+ Hits 1737 1748 +11
- Misses 38 57 +19
Continue to review full report at Codecov.
|
Hmm, I'll add a test for the @dynamicCallable code that's not currently covered. |
Thanks for the PR. I would like to include some kind of support for this but I've never quite worked out a satisfactory model. The part of this PR's approach that goes wrong is to do with methods with default arguments. Minimally consider: class C
def f(a = 2)
a
end
end So But because the approach 'eagerly' evaluates I think my least bad solution to this ambiguity was to drop the eager dynamic member lookup part, forcing users to always write explicit method calls Perhaps your fresh eyes can see a better way through this! |
Oh, right. It didn't even occur to me that methods with default arguments would behave differently. Hmm, yeah I see what you mean about it not being ideal to have to put parentheses on every Ruby method that idiomatic Ruby treats more like properties. It does seem more "Swifty" to me though. As does getting a method reference back without the parens that you could potentially call later with parens. |
Actually, thinking about this more, It would add a lot of idiosyncrasy in that you'd have to only use parens to call a method if all its arguments have default values. Also some methods without parens would give you a method reference, and some would give you the result of the method, without a very good way to know beforehand without carefully checking the method signature and keeping these non-Ruby/non-Swift rules in mind. |
And, I just realized this doesn't handle named parameters at all... I'm going to flesh this out more. |
I agree with this. I think it's important that this type not be e: thinking about it,
Yes it should just be boilerplate to add the call variants once the object model is sound. |
This adds dynamic callable and member lookup. I uncommented the commented out tests in
TestDynamic.swift
and they pass. Is this something you'd be open to merging?I can add the dynamic call syntax to a section in the
README.md
if you'd like.