[erlang-bugs] no documentation for module_info and get_module_info

[Fred Youhanaie]

in-line ...

On 27/11/13 10:27, Anthony Ramine wrote:
> Replied inline.
>
>Le 27 nov. 2013 à 10:22, Fred Youhanaie <fly@REDACTED> a écrit :
> ...
>
>> 1. erlang:get_module_info/1 and erlang:get_module_info/2 need to be
>>   documented in the ERTS manual.
>
>Why would you put it in the public documentation when it is an implementation detail (cf. for example the comment about module_info in ops.tab [1])? Why not call M:module_info()?

Although the original intention was to improve the implementation,
nevertheless, it can provide useful functionality for other uses,
provided that it is stable and safe to use. If it's not meant to be used
publicly, then the documentation should say so. Lack of documentation
will not stop others from blindly using it!

>> 2. The documentation for module_info/0 and module_info/1 need to clarify
>>   that they will always return info for the current version of a loaded
>>   module, rather than the version that is active for the caller.
>>
>> 3. Can #2 above be fixed so that it returns data related to the active
>>   module, rather than the current version?
>
>2 and 3 may be a problem in the context of calling module_info directly as a local function from the very same module. If you call foo:module_info from the module bar, it would make absolutely no sense to return anything else but the current version.

On the contrary, module_info, as opposed to M:module_info, should behave
in the same way as other functions. If not, then either it should be
fixed or the exceptional behaviour documented.

>But then again, if your application depends on this, you are probably doing something really unusual.

There is nothing unusual about introspection within dynamic/scripting
languages. In one particular case this means that I cannot rely on the
Vsn attribute to give me the correct version when there are two versions
of the module loaded.

f.