Extending Functionality: an expedient and questionable approach

[Shawn Pearce]

Chris Pressey <chris_pressey@REDACTED> wrote:
> What it does is this.  If you call an undefined function in any module, it looks to see if that
> module exports a function called undefined_function/2. If it does, it calls that instead with
> (Func, Args) as the arguments. If not, it crashes like usual.

I had a use for something like this just the other day in Erlang,
but it now escapes me what it was.

<sarcastic>
I think having this in the base language would let us finally see
Erlang be a 'real' language, as both Perl and Python have this feature
and they are 'real' langauges while Erlang is still a toy.  :-)
</sarcastic>

What a slippery slope this presents.  :)  Its quite a nifty feature,
and goes right along with -import.  Being able to pull in common
code to appear as 'local' calls (for shorthand typing) but keeping them
remote goes right along with being able to inherit exported functions.

I'd almost rather see this as a compiler option though, as we shouldn't
really be allowing purely dynamic function names to be used.  Perhaps
use something like:

-inherit(egui, [hide/1, show/1, display/1]).

and the compiler generates:

-export([hide/1,show/1,display/1).
hide(A) -> egui:hide(A).
show(A) -> egui:show(A).
display(A) -> egui:display(A).

AFAIK, this can be a parse transform or something.  But I haven't
looked that deep into it.  Perhaps a -inherit(egui) would just import
all exported functions declared in egui which are not defined already
by -export statements.  (Thus if we implement our own hide/1 to override
what egui would have given us, we must export it or else the compiler
would attempt to redefine it.)


-- 
Shawn.

  You will have good luck and overcome many hardships.