[erlang-bugs] no documentation for module_info and get_module_info

[Fred Youhanaie]

in-line

On 27/11/13 11:39, Robert Virding wrote:
> Comment to a comment further down.
>
> Robert
>
> ----- Original Message -----
>> From: "Anthony Ramine" <n.oxyde@REDACTED>
>>
>> Replied inline.
>>
>> --
>> Anthony Ramine
>>
>> Le 27 nov. 2013 à 10:22, Fred Youhanaie <fly@REDACTED> a écrit :
>>
>>> Hi
>>>
>>> I came across this thread from five years ago:
>>>
>>> http://erlang.org/pipermail/erlang-questions/2008-October/038848.html
>>>
>>> Was a bug report raised? If not, I'd like to raise one please :-)
>>>
>>> 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()?
>
> I agree there is no reason to document these. They are internal and there is never any reason to call them.
>

Well, judging by the related thread on erlang-questions, the internal functions are known and publicly accessible.
So, perhaps the documentation can be a DO NOT USE notice!

>>> 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.
>
> I agree here. Doing a fully qualified call to a function in a module always gives you the current version so calling foo:module_info() should behave the same way. In the same vein using erlang:get_module_info/1/2 should also behave in the same way and give the current version otherwise you could get some really weird and inconsistent behaviour. For example if you call it from within the module foo you would get the "active" version for the caller, but what if you are in a function in another module which has been called from module foo? Which version would you get then, the current version or the "active" version you are "in"? Convoluted I know, but things like this need to be decided, and preferably consistent.
>
> However, doing a local call to module_info should give you the active version, which it doesn't today. The module_info/1/2 don't simply return a pre-built data structure but do call erlang:get_module_info/1/2 which is the root of the problem. Back in the (really) old days we did generate the data structure at compile time so this wasn't a problem. Though I can't remember anyone actually calling module_info locally.
>

Yes, and my query all along has been about the local call (mis)behaviour, which needs to be fixed or documented.
Although not used before, module_info/0/1 and perhaps even the BIF counterparts, can be useful introspection tools.
Programmers today tend to leverage what is available to them in all sorts of ways :-)


Cheers

f.