<div dir="ltr">Hi,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 22, 2013 at 12:10 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 01/22/2013 07:34 AM, Björn Gustavsson wrote:<br>


</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Why not use the existing -export() attribute and write like<br>

</div></blockquote><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
this:<br>
<br>
-export([monitor/2,demonitor/<u></u>1]).<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>
</blockquote>
<br></div>
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></blockquote><div><br></div><div style>I'm sorry, but I don't think you are answering Björn's question. For this particular case, why not write regular Erlang like</div><div style><br></div><div>first_name(Model) -> get(first_name, Model).</div>

<div>last_name(Model) -> get(last_name, Model).</div><div style>get(F, [Model]) -><br></div><div style>    {_, Value} = lists:keyfind(F, 1, Model),<br>    Value.<br></div><div> </div><div style>which is much clearer to understand. One argument might be that there is some duplication, but I think that it could be handled with much more elegance if we had abstract patterns implemented.</div>

<div style><br></div><div style>Do you have a more relevant example where using $handle_undefined_function gives significant advantage?</div><div style><br></div><div style>best regards,</div><div style>Vlad</div><div><br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
As you can see he doesn't have to worry about adding clauses to handle undef, which is good.<br>
<br>
This also still allows you to do -extends:<br>
<br>
%% Functions you override.<br>
-export([ponies/1]).<br>
<br>
%% Functions you don't.<br>
-attr([horses/1, cows/1]).<br>
<br>
$handle_undefined_function(F, Args) -><br>
    apply(base_module, F, Args).<br>
<br>
Again you still don't have to handle undef.<br>
<br>
Tools can expect these functions. If you allow specs for undefined functions then Dialyzer can also act as if they were defined normally.<br>
<br>
Implementing it like this, without pushing the burden of handling undef to the user, would avoid making half the community scream in terror and endlessly ask for the removal of the feature (like with pmods).<div class="">

<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>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div></div>