Extending Functionality: an expedient and questionable approach

[Chris Pressey]

On Thu, 13 Mar 2003 17:56:45 -0500
Shawn Pearce <spearce@REDACTED> wrote:

> Its really a problem when both modules implement undefined_function/2
> and somehow enter into each referring to the other.  Rare in OO cases,
> but possible if someone makes a mistake in one or the other module.

Yes.  Hmmm... another problem involving cycles.  Interesting.
Now, if undefined_function/2 were to keep a visited-list... ;)

Actually, just out of curiousity, does anyone know if there's a better way
to investigate the call stack -  better than the only method I've seen so
far, that is, to catch an intentional error and examine the result?

Also, calls like ?MODULE:function() (I noticed et has them, presumably for
hot swapping code) could lead this right down the garden path when used in
undefined_function/2.  The compiler can't tell they don't exist (last I
checked, it's very trusting about m:f type calls.)

So in general, better to avoid this and turn to something nicer:

> I still prefer the compiler-based -inherit I suggested in my last
> email,

Me too.  A parse transform is definately a better way to go.

> as it is very explicit to both the compiler, runtime and
> developer(s) about what is happening, what is available, etc.  The
> 'special' handling through undefined_function is cute, as you can
> now do:
> 
> 	-module(os).
> 	undefined_function(F, [A]) ->
> 		os:cmd(atom_to_list(F) ++ " " ++ A).
> 
> 
> 	os:rm("the file.txt").
> 	os:ls("mydir").
> 	os:find("mydir -type f").
> 
> etc.

Cute, yes indeed (and some do this in Perl too IIRC)...
but 'cute' doesn't build very good bridges.

Hmmm... very educational experience though.

I'll see if I can whip up a parse transform in my next batch of spare
time, and see how that fares.

Thanks,
-Chris