-
Notifications
You must be signed in to change notification settings - Fork 323
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
Type.to_text shall invoke instance method #6300
Comments
should the title say "instance method", not "static method", or am i just reading it wrong? |
The discussion is not finished and we are chatting about this design with Radek actively. The change proposed by Radek is incompatible with how types are intended to work and this topic needs a lot more work/thinking before making such radical changes. We should revisit this topic in approx 1 week. |
@wdanilo please note that this issue isn't implementing Radek's proposal. No incompatible changes, no syntax changes, no radical changes. This issue proposes minimal change and only affects how methods defined on
We already have at least three duplicates and counting. The current behavior of |
I've just chatted with @wdanilo and Wojciech is fine with us implementing this issue, as long as it only affects dispatch of methods defined on |
This change modifies method dispatch for methods that override Any's definitions. When an overrided method is invoked statically we call Any's method to stay consistent. This change primarily addresses the plethora of problems related to `to_text` invocations. It does not attempt to completely modify method dispatch logic. Closes #6300.
This change modifies method dispatch for methods that override Any's definitions. When an overrided method is invoked statically we call Any's method to stay consistent. This change primarily addresses the plethora of problems related to `to_text` invocations. It does not attempt to completely modify method dispatch logic. Closes #6300.
Hubert Plociniczak reports a new STANDUP for yesterday (2023-04-26): Progress: Investigating special logic for methods that override Any's definitions. Draft PR is ready, most of corner cases seem to be covered. It should be finished by 2023-04-27. Next Day: Next day I will be working on the #6300 task. Investigating a, potentially simpler solution, that involves first resolved the symbol for Any and then for self's type. |
Hubert Plociniczak reports a new STANDUP for today (2023-04-27): Progress: More testing, addressing PR review. Went back to #6257 to address PR review. Investigating various LS bugs like #6447 or #6395 It should be finished by 2023-04-27. Next Day: Next day I will be working on the #6395 task. Debugging LS bugs. |
This change modifies method dispatch for methods that override Any's definitions. When an overrided method is invoked statically we call Any's method to stay consistent. This change primarily addresses the plethora of problems related to `to_text` invocations. It does not attempt to completely modify method dispatch logic. Closes #6300.
To turn the #6216 discussion into some practical resolution I propose following improvement:
If a method
x
is defined onAny
, then the only "static call" syntax isAny.x
. Every other form is an instance invocation. E.g.My_Type.x
invokes the instance method withself=My_Type
(that's actually the current behavior). The same wayWith_X.x
should be the instance invocation (that has to change for types that overridex
).The only identified drawback is that we don't have a way to invoke
With_X.x
statically. Let's ignore that, fix the above problem (which is really painful) and see whether we need to fix the identified drawback as well (so far we aren't aware of any such need).The text was updated successfully, but these errors were encountered: