Hi Francesco,<div><br></div><div>Do you mean that after your update these types have to be moved within the behaviour file itself? If this is the case, you could export them using the "-export_type" attribute and then use them as remote types: "behaviour_module:type_name()". You can use them in this way in both specs and other -type definitions and at least Dialyzer won't have any problem at all.</div><div><br></div><div>Stavros<br><br>On Tuesday, April 24, 2012 5:42:58 PM UTC+3, Francesco Mazzoli wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,<p>I have recently updated some code to use the new callback signatures for <br>behaviours. Before that, we simply used a .hrl file that we included in <br>each implementing module.</p><p>While hacky, the old approach had an advantage: we could include in the <br>.hrl specs some types that were to be defined in the including file, and <br>then used in type signatures.</p><p>It would be useful to be able to parametrize behaviours by type more <br>nicely, since most behaviours specs are dominated by 1 or 2 types <br>(classically some kind of state) and as of now no typechecking takes <br>place on those types. That might be achieved with some pre-processor <br>directive, e.g. -behaviour_type(whatever).</p><p>What do you think?</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><br>On Tuesday, April 24, 2012 5:42:58 PM UTC+3, Francesco Mazzoli wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,<p>I have recently updated some code to use the new callback signatures for <br>behaviours. Before that, we simply used a .hrl file that we included in <br>each implementing module.</p><p>While hacky, the old approach had an advantage: we could include in the <br>.hrl specs some types that were to be defined in the including file, and <br>then used in type signatures.</p><p>It would be useful to be able to parametrize behaviours by type more <br>nicely, since most behaviours specs are dominated by 1 or 2 types <br>(classically some kind of state) and as of now no typechecking takes <br>place on those types. That might be achieved with some pre-processor <br>directive, e.g. -behaviour_type(whatever).</p><p>What do you think?</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>