Extending Functionality: an expedient and questionable approach
Fri Mar 14 00:40:49 CET 2003
On Thu, 13 Mar 2003 17:56:45 -0500
Shawn Pearce <> 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
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:
> undefined_function(F, [A]) ->
> os:cmd(atom_to_list(F) ++ " " ++ A).
> os:rm("the file.txt").
> os:find("mydir -type f").
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.
More information about the erlang-questions