Ok, I understand your original approach now. It is indeed clever and reduces duplication.<div><br></div><div>The only solution I can think of, while still using -callback attributes, is to keep both the callback attributes and the old hrl file and end up with two duplicate definitions (one in the callback attributes and one in the specs that would be included and completed by the types in each callback module). I agree that it is bad practice, but remember that Dialyzer will check that the definitions are compatible so you will be actively protected from code rot. <div><br></div><div>Callback attributes were added mainly as a way way to describe a behaviour's interface better than comments and a list of exports that originally existed. The benefit of using them instead of included -specs is that you can have generic -callback attributes and more specific specs in each callback module. In your case, where little or no further refinement is needed, it turns out that using them leads to duplication.</div><div><br></div><div>As a final note, remember that you can always choose to shut off warning categories. In your case it might be simpler to just shut off behaviour-related warnings.<br><br>Stavros<br><br>On Tuesday, April 24, 2012 10:27:18 PM UTC+2, Francesco Mazzoli wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24/04/12 21:15, Stavros Aronis wrote:<br>> I do not want to go much further with this, but I fail to understand<br>> what kind of changes would trigger this need for extensive changes. If<br>> the behaviour code needs to be agnostic of the type of this state<br>> variable and "term()" needs not be changed due to this reason. The type<br>> definitions are already in every module because that's where the<br>> specialization is being made. On the other hand, if the same type is<br>> used in many modules then it should be defined in the behaviour module<br>> and exported. Then it can be used in all of them, without any need of<br>> copying. Could you provide a more detailed example?<br>><br>> Stavros<p>It's not even that much about changing code, it's just that doing what <br>you propose (re-spec'ing all the definitions in the module) is an ugly, <br>ugly solution, and there is no need for it. Code repetition is bad, and <br>this is a form of it.</p><p>I don't understand what you mean with "the behaviour code needs to be <br>agnostic of the type of this state variable ...".</p><p>By the way, what we did before implements what you're saying, but a bit <br>better, since we only needed to define the specs once and then include <br>them each time. In this case we'd always need to define them at least twice.</p><p>Example: we have a behaviour `rabbit_backing_queue': <br><a href="https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_backing_queue.erl" target="_blank">https://github.com/rabbitmq/<wbr>rabbitmq-server/blob/master/<wbr>src/rabbit_backing_queue.erl</a> <br>. The types `ack()' and `state()' are specific to the implementation. An <br>example implementation is rabbit_variable_queue ( <br><a href="https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_variable_queue.erl" target="_blank">https://github.com/rabbitmq/<wbr>rabbitmq-server/blob/master/<wbr>src/rabbit_variable_queue.erl</a> <br>) implements this behaviour, and defines ack() and state() types, which <br>are now unused. Following your suggestion I'd have to re-define the <br>15-or so methods in rabbit_backing_queue, which is really undesirable - <br>I'd rather just leave things as they are.</p><p>Francesco.<br>______________________________<wbr>_________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br></p><p></p><p></p><p></p><p></p></blockquote></div></div>