gen_statem:start_monitor dialyzer warning

Raimo Niskanen raimo+erlang-questions@REDACTED
Tue Jan 26 10:37:54 CET 2021


On Mon, Jan 25, 2021 at 09:46:34PM +0100, Kostis Sagonas wrote:
> On 1/25/21 12:52 PM, Raimo Niskanen wrote:
> > There is room for improvement here.
> 
> Yep, definitely.  Let me throw my 2 :-
> 
> > Here gen does not export the right type for gen:start(_, monitor, ...).
> > I am not sure that we should specify types in gen; it is an internal module,
> 
> For a long time now, my view has been that for OTP folks, `internal 
> modules' are similar to what `unicorns' are for my little daughter. 
> They are imaginary creatures which are "goosey" and nice.
> 
> But in reality, they do not really exist.  Moreover, they might look 
> innocent and nice, but they have a horn that they can put to use if 
> strangers manage to put their hands on them.
> 
> 
> Seriously now, in an open source code base, you cannot expect that you 
> would have a key module with a name ('gen') which is the second most 
> general name that I can think of (question for the reader: guess what is 
> the most `general` one?) and that this module will "just pollute the 
> name space" and will not be looked at or abused by any of the thousands 
> of developers who use Erlang/OTP.
> 
> 
> My view is that you should *not* have such modules in a system!
> 
> If they are really intended to be `internal', their functions should 
> only appear *inside* the modules that they support.  If they are used by 
> multiple modules and you are worried about code duplication, simply have 
> them as include files.
> 
> That's my view/advice at least.
> 
> Kostis

Given that 'gen' is an undocumented helper module in stdlib that is about
15..20 years older than Dialyzer, I was wondering about if, as long as it
still is undocumented, would it be better to not have type specifications
in it, possibly?

We are still struggling with best practices for Dialyzer in an old large
code base...

Best regards
-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


More information about the erlang-questions mailing list