-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Support (exported) macros with defoverridable/super #4848
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
Conversation
@@ -32,6 +32,13 @@ name(_Module, {Name, _} = Function, Overridable) -> | |||
{Count, _, _, _} = maps:get(Function, Overridable), | |||
elixir_utils:atom_concat([Name, " (overridable ", Count, ")"]). | |||
|
|||
%% Returns the kind (def, defp, and so on) of the given overridable function. | |||
|
|||
kind(Module, FunctionOrMacro) -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can rename the name
function to kind_and_name
and return both kind and name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd need to return the FinalArgs
as well (cause we want to add the '_@CALLER'
arg), this is why I didn't go with kind_and_name
(which is what I wanted to go with for the record 😄). Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could still calculate the args later on. The benefit of kind_and_name is just to avoid doing multiple lookups both in this module and in the translator. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I see what you mean now. Updated, let me know how it looks :)
It looks great to me, just one tiny comment left. |
@@ -1,6 +1,6 @@ | |||
% Holds the logic responsible for defining overridable functions and handling super. | |||
-module(elixir_def_overridable). | |||
-export([setup/1, overridable/1, overridable/2, name/2, super/2, store_pending/1, | |||
-export([setup/1, overridable/1, overridable/2, name/2, kind_and_name/2, super/2, store_pending/1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still need to export name/2
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually we don't, good catch! We don't need name/2
at all, I just removed it. We could go even further and make name/3
take a Count
instead of the whole Overridable
map because we always have that count available, but I think for now it's fine like this, name/2
is nice and scoped like this. Wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@josevalim aaaand done! 👍 |
Ship it. |
This is a WIP PR that I'd really like to collect feedback on; it's a possible partial fix for #4830 as it fixes
super()
anddefoverridable
for public macros but not private macros.Is this a good way to approach this? :)