<div dir="ltr">Ok, I see. I had lost track of who suggested the example originally.<div><br></div><div style>I suppose that the functions listed in -attr() would have to be included in an -export() too if they are to be public?</div>
<div style><br></div><div style>regards,</div><div style>Vlad</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 22, 2013 at 1:25 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 01/22/2013 01:10 PM, Vlad Dumitrescu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Jan 22, 2013 at 1:02 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></div><div class="im">
<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
<br>
On 01/22/2013 12:57 PM, Vlad Dumitrescu wrote:<br>
<br>
Hi,<br>
<br>
On Tue, Jan 22, 2013 at 12:10 PM, Loïc Hoguin<br>
<<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a> <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>><br></div><div class="im">
<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a> <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>>> wrote:<br>
<br>
On 01/22/2013 07:34 AM, Björn Gustavsson wrote:<br>
<br>
Why not use the existing -export() attribute and write like<br>
<br>
this:<br>
<br></div>
-export([monitor/2,demonitor/_<u></u>___1]).<div><div class="h5"><br>
<br>
<br>
monitor(process, Pid) -><br>
do_something.<br>
<br>
demonitor(Pid) -><br>
do_something_else().<br>
<br>
So what would be the advantage of your version?<br>
<br>
<br>
It still allows Evan Miller to write this:<br>
<br>
-attr([first_name/1, last_name/1, ...]).<br>
<br>
$handle_undefined_function(F, [Model]) -><br>
{_, Value} = lists:keyfind(F, 1, Model),<br>
Value.<br>
<br>
<br>
I'm sorry, but I don't think you are answering Björn's question. For<br>
this particular case, why not write regular Erlang like<br>
<br>
first_name(Model) -> get(first_name, Model).<br>
last_name(Model) -> get(last_name, Model).<br>
get(F, [Model]) -><br>
{_, Value} = lists:keyfind(F, 1, Model),<br>
Value.<br>
which is much clearer to understand. One argument might be that<br>
there is<br>
some duplication, but I think that it could be handled with much<br>
more<br>
elegance if we had abstract patterns implemented.<br>
<br>
Do you have a more relevant example where using<br>
$handle_undefined_function gives significant advantage?<br>
<br>
<br>
That's a question about $handle_undefined_function in general, not<br>
about this specific implementation proposal. Björn is the one who<br>
wrote the current implementation that's now in master, I don't have<br>
to tell him what can be done with it, he knows. I do have to tell<br>
him how implementing it this way improves the usage, though. Which<br>
is the sole reason of this thread.<br>
<br>
<br>
Maybe I'm confused, but your answer would make 100% sense if Björn's<br>
question would have been<br>
<br>
"<br>
Why not use the existing -export() attribute and write like this:<br>
-export([monitor/2,demonitor/<u></u>1]).<br></div></div>
$handle_undefined_function(__<u></u>monitor, [process, Pid]) -><br>
do_something();<br>
$handle_undefined_function(__<u></u>demonitor, Pid) -><div class="im"><br>
do_something_else().<br>
"<br>
<br>
My question is a follow-up on his own formulation, where your suggestion<br>
is compared with an implementation not using $handle_undefined_function<br>
at all.<br>
</div></blockquote>
<br>
And I answered it based on known potential uses. The snippet you quote was made to demonstrate the flaws in the current implementation, not to demonstrate an interesting use of the feature. It can be demonstrated using Evan's example too, for example:<br>
<br>
$handle_undefined_function(F, [Model]) when is_list(Model) -><div class="im"><br>
{_, Value} = lists:keyfind(F, 1, Model),<br></div>
Value;<div class="im"><br>
$handle_undefined_function(F, Args) -><br>
error_handler:raise_undef_<u></u>exception(?MODULE, F, Args).<br>
<br></div>
This would be an incorrect implementation of Evan's use for it, and nothing about it says "It's obvious!". And yet it's still wrong. Correct implementation would be:<br>
<br>
$handle_undefined_function(F, [Model]) when is_list(Model) -><div class="im"><br>
{_, Value} = lists:keyfind(F, 1, Model),<br></div>
Value;<br>
$handle_undefined_function(F, Args) -><br>
case lists:member({F, length(Args)},<br>
[{first_name, 1}, {last_name, 1}, ...]) of<br>
true -> erlang:error(badarg);<br>
false -> error_handler:raise_undef_<u></u>exception(?MODULE, F, Args)<br>
end.<br>
<br>
With my proposal he can write:<br>
<br>
-attr([first_name/1, last_name/1]).<br>
<br>
$handle_undefined_function(F, [Model]) when is_list(Model) -><div class="im"><br>
{_, Value} = lists:keyfind(F, 1, Model),<br>
Value.<br>
<br></div>
This makes error_handler properly handle undef errors, reduces the code needed to use the feature, allow tools to behave nicely when using the feature, etc.<br>
<br>
As for why Evan would use $handle_undefined_function instead of creating many functions, that's for him to decide. But both implementations of $handle_undefined_function allow all known uses of the feature, yet only one gets error handling and tools support straight.<div class="HOEnZb">
<div class="h5"><br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
</div></div></blockquote></div><br></div>