[erlang-questions] Improve $handle_undefined_function

Loïc Hoguin <>
Tue Jan 22 13:34:06 CET 2013


I don't think they can appear as exported, due to error_handler's use of 
function_exported to know if it's defined. The attribute can be named 
something like -undef-export([]) though, to make it clearer. Note that 
the feature is only applicable when the function is called through 
M:F(...), not local calls, because the module wouldn't compile.

On 01/22/2013 01:30 PM, Vlad Dumitrescu wrote:
> Ok, I see. I had lost track of who suggested the example originally.
>
> I suppose that the functions listed in -attr() would have to be included
> in an -export() too if they are to be public?
>
> regards,
> Vlad
>
>
> On Tue, Jan 22, 2013 at 1:25 PM, Loïc Hoguin <
> <mailto:>> wrote:
>
>     On 01/22/2013 01:10 PM, Vlad Dumitrescu wrote:
>
>         On Tue, Jan 22, 2013 at 1:02 PM, Loïc Hoguin <
>         <mailto:>
>         <mailto: <mailto:>>> wrote:
>
>              On 01/22/2013 12:57 PM, Vlad Dumitrescu wrote:
>
>                  Hi,
>
>                  On Tue, Jan 22, 2013 at 12:10 PM, Loïc Hoguin
>                  < <mailto:>
>         <mailto: <mailto:>>
>                  <mailto: <mailto:>
>         <mailto: <mailto:>>>> wrote:
>
>                       On 01/22/2013 07:34 AM, Björn Gustavsson wrote:
>
>                           Why not use the existing -export() attribute
>         and write like
>
>                           this:
>
>                           -export([monitor/2,demonitor/______1]).
>
>
>
>                           monitor(process, Pid) ->
>                                do_something.
>
>                           demonitor(Pid) ->
>                                do_something_else().
>
>                           So what would be the advantage of your version?
>
>
>                       It still allows Evan Miller to write this:
>
>                       -attr([first_name/1, last_name/1, ...]).
>
>                       $handle_undefined_function(F, [Model]) ->
>                            {_, Value} = lists:keyfind(F, 1, Model),
>                            Value.
>
>
>                  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
>
>                  first_name(Model) -> get(first_name, Model).
>                  last_name(Model) -> get(last_name, Model).
>                  get(F, [Model]) ->
>                        {_, Value} = lists:keyfind(F, 1, Model),
>                        Value.
>                  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.
>
>                  Do you have a more relevant example where using
>                  $handle_undefined_function gives significant advantage?
>
>
>              That's a question about $handle_undefined_function in
>         general, not
>              about this specific implementation proposal. Björn is the
>         one who
>              wrote the current implementation that's now in master, I
>         don't have
>              to tell him what can be done with it, he knows. I do have
>         to tell
>              him how implementing it this way improves the usage,
>         though. Which
>              is the sole reason of this thread.
>
>
>         Maybe I'm confused, but your answer would make 100% sense if Björn's
>         question would have been
>
>         "
>             Why not use the existing -export() attribute and write like
>         this:
>                   -export([monitor/2,demonitor/__1]).
>         $handle_undefined_function(____monitor, [process, Pid]) ->
>                       do_something();
>                   $handle_undefined_function(____demonitor, Pid) ->
>
>                       do_something_else().
>         "
>
>         My question is a follow-up on his own formulation, where your
>         suggestion
>         is compared with an implementation not using
>         $handle_undefined_function
>         at all.
>
>
>     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:
>
>     $handle_undefined_function(F, [Model]) when is_list(Model) ->
>
>          {_, Value} = lists:keyfind(F, 1, Model),
>          Value;
>
>     $handle_undefined_function(F, Args) ->
>          error_handler:raise_undef___exception(?MODULE, F, Args).
>
>     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:
>
>     $handle_undefined_function(F, [Model]) when is_list(Model) ->
>
>          {_, Value} = lists:keyfind(F, 1, Model),
>          Value;
>     $handle_undefined_function(F, Args) ->
>          case lists:member({F, length(Args)},
>                  [{first_name, 1}, {last_name, 1}, ...]) of
>              true -> erlang:error(badarg);
>              false -> error_handler:raise_undef___exception(?MODULE, F,
>     Args)
>          end.
>
>     With my proposal he can write:
>
>     -attr([first_name/1, last_name/1]).
>
>     $handle_undefined_function(F, [Model]) when is_list(Model) ->
>
>          {_, Value} = lists:keyfind(F, 1, Model),
>          Value.
>
>     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.
>
>     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.
>
>
>     --
>     Loïc Hoguin
>     Erlang Cowboy
>     Nine Nines
>     http://ninenines.eu
>
>


-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu



More information about the erlang-questions mailing list