Simple xref question

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Simple xref question

Joe Williams-2

    How can I find all functions in the standard system that call
a given function {Mod,Func,Arity}?

    Is their a one-liner to do this?


   /Joe






Reply | Threaded
Open this post in threaded view
|

Simple xref question

Thomas Lindgren-3
>    How can I find all functions in the standard system that call
>a given function {Mod,Func,Arity}?
>
>   Is their a one-liner to do this?

You can pass the option {use, MFAs} to 'analyze' once you have the analyzer
running, it seems. Alas, I don't think apply/spawn is handled the way one
wants. (They are treated as "unresolved calls" in general.)

This is annoying so here is a proposal for Son of Erlang: new directives.

-export([f/n, ...]).
-apply([f/n, ...]).
-spawn([f/n, ...]).

An -export means the functions can be called remotely, mod:f(...).
An -apply means the functions can be invoked by apply.
A -spawn means the functions can be spawned.

There are two advantages to this:

1. Programmers can ensure that a function only can be called
   directly, by ONLY -export:ing it, which means xref will find all
references to it.

2. No need for the "internal exports" that dot the code, e.g., when
   one needs to spawn certain servers. If f/n is -spawn declared
   but not -export:ed, then it will not be visible to the outside.

I think such an extension (though non-compatible, since -export does all
three today) would clean up some annoyances, remove some queer coding
practices and generally usher in an era of utopical bliss.

-- Thomas



Reply | Threaded
Open this post in threaded view
|

Simple xref question

Joe Williams-2
On Thu, 25 Apr 2002, Thomas Lindgren wrote:

> >    How can I find all functions in the standard system that call
> >a given function {Mod,Func,Arity}?
> >
> >   Is their a one-liner to do this?
>
> You can pass the option {use, MFAs} to 'analyze' once you have the analyzer
> running, it seems. Alas, I don't think apply/spawn is handled the way one
> wants. (They are treated as "unresolved calls" in general.)
>

  That much I had understood -

  Is there a convenient way of loading every module in the system
prior to doing the analysis??

  BTW to my relief I find there are a few undocumented functions in
xref.erl namely, analyse/2 and analyse/3 that can be used instead of
analyze/2 and analyze/3.



> This is annoying so here is a proposal for Son of Erlang: new directives.
>
> -export([f/n, ...]).
> -apply([f/n, ...]).
> -spawn([f/n, ...]).
>
> An -export means the functions can be called remotely, mod:f(...).
> An -apply means the functions can be invoked by apply.
> A -spawn means the functions can be spawned.
>
> There are two advantages to this:
>
> 1. Programmers can ensure that a function only can be called
>    directly, by ONLY -export:ing it, which means xref will find all
> references to it.
>
> 2. No need for the "internal exports" that dot the code, e.g., when
>    one needs to spawn certain servers. If f/n is -spawn declared
>    but not -export:ed, then it will not be visible to the outside.
>
> I think such an extension (though non-compatible, since -export does all
> three today) would clean up some annoyances, remove some queer coding
> practices and generally usher in an era of utopical bliss.

Utopical bliss indeed - what a cornucopic joy your postings are.

/Joe

>
> -- Thomas
>
>