[erlang-questions] What is the fastest way to check if a function is defined in a module?

[Michael Truog]

On 03/07/2018 12:43 AM, Richard Carlsson wrote:
> Using code:is_loaded/1 has the same roundtrip overhead as code:ensure_loaded(), so in that case you can just use the latter directly without any extra check.
>
> But as I see it, the warning should just be seen as a pointer for average users to primarily use the code module, and not as a warning about this function possibly going away or being bad for you, as long as you know what you are using it for.

If that really is the case with erlang:module_loaded/1, then it would be best to updated the documentation so the warning is less severe.  That would make it clear that the function isn't a maintenance hazard in the future, because it may disappear or change in the future.  The warning currently says "This BIF is intended for the code server (see code(3)) and is not to be used elsewhere." which is similar to erlang:purge_module/1, erlang:delete_module/1, and erlang:load_module/2.  So the same change to the documentation should occur with these functions too.


>
>
>         /Richard
>
> 2018-03-07 8:24 GMT+01:00 Michael Truog <mjtruog@REDACTED <mailto:mjtruog@REDACTED>>:
>
>     On 03/06/2018 10:54 PM, Metin Akat wrote:
>>     Thanks all. I went with the solution Richard proposed. And after testing of the full implementation, this check is certainly not the bottleneck of the system, as Jesper suggested.
>
>     The only problem with that, is that the documentation specifies that erlang:module_loaded/1 is only really meant to be used by the code server (at http://erlang.org/doc/man/erlang.html#module_loaded-1 <http://erlang.org/doc/man/erlang.html#module_loaded-1>). If that bothers you, you should use the function code:is_loaded/1 instead.
>
>
>
>>
>>
>>         On Tue, Mar 6, 2018, at 12:23 PM, Richard Carlsson wrote:
>>>         I was actually considering submitting such a patch a while back, but one argument against making that short-cut could be that operations against the code server should be serialized. On the other hand I haven't yet come up with an example where the short-cut would make a difference that couldn't already happen due to processor scheduling.
>>>
>>>
>>>                 /Richard
>>>
>>>         2018-03-06 16:40 GMT+01:00 Michał Muskała <michal@REDACTED <mailto:michal@REDACTED>>:
>>>
>>>
>>>             On 6 Mar 2018, 16:36 +0100, Richard Carlsson <carlsson.richard@REDACTED <mailto:carlsson.richard@REDACTED>>, wrote:
>>>
>>>
>>>>
>>>>             is_exported(M, F, A) ->
>>>>               case erlang:module_loaded(M) of
>>>>                 false -> code:ensure_loaded(M);
>>>>                 true -> ok
>>>>               end,
>>>>             erlang:function_exported(M, F, A).
>>>>
>>>>             (code:ensure_loaded() is slow compared to the fast call to erlang:module_loaded(), even if the module is already in memory).
>>>>
>>>
>>>             I was recently wondering about this. Is there a reason code:ensure_loaded() does not short circuit using erlang:module_loaded()? It could probably even skip the request to the code server entirely in case the module is already loaded.
>>>
>>>
>>>             Michał.
>>>
>>>
>>>         _________________________________________________
>>>         erlang-questions mailing list
>>>         erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>>         http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
>>
>>
>>         _______________________________________________
>>         erlang-questions mailing list
>>         erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>         http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
>>
>>
>>
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>     http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180307/49551df7/attachment.htm>