<div dir="ltr">Hi!<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 17, 2014 at 5:21 PM, Kostis Sagonas <span dir="ltr"><<a href="mailto:kostis@cs.ntua.gr" target="_blank">kostis@cs.ntua.gr</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 05/17/2014 05:03 PM, Vlad Dumitrescu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The current implementation looks like it just goes through the different<br>
checks sequentially, so it shouldn't be a huge amount of work to extract<br>
the steps to separate modules.<br>
</blockquote>
<br></div>
Please don't. This is a terrible idea. Among other reasons, there is no point in further polluting the module name space.<span class="HOEnZb"><font color="#888888"><br>
<br>
Kostis<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Ok, I can agree with that. Then the plug-in checkers should be functions and the default ones could still be located in erl_lint. </div><div class="gmail_extra">

<br></div><div class="gmail_extra">The reason I said modules was that in the general case a plug-in may have multiple API/SPI entry points and in Erlang the only structure above functions is a module. I can imagine having the concept of modules separated from that of a source code file (i.e. dynamic modules) and those could be applied here, but I feel that is a discussion that I am not ready for at this moment. </div>

<div class="gmail_extra"><br></div><div class="gmail_extra">regards,</div><div class="gmail_extra">Vlad</div><div class="gmail_extra"><br></div></div>