[erlang-questions] [Dialyser] Type parametrized behaviours

Francesco Mazzoli francesco@REDACTED
Tue Apr 24 22:27:18 CEST 2012


On 24/04/12 21:15, Stavros Aronis wrote:
> I do not want to go much further with this, but I fail to understand
> what kind of changes would trigger this need for extensive changes. If
> the behaviour code needs to be agnostic of the type of this state
> variable and "term()" needs not be changed due to this reason. The type
> definitions are already in every module because that's where the
> specialization is being made. On the other hand, if the same type is
> used in many modules then it should be defined in the behaviour module
> and exported. Then it can be used in all of them, without any need of
> copying. Could you provide a more detailed example?
>
> Stavros

It's not even that much about changing code, it's just that doing what 
you propose (re-spec'ing all the definitions in the module) is an ugly, 
ugly solution, and there is no need for it. Code repetition is bad, and 
this is a form of it.

I don't understand what you mean with "the behaviour code needs to be 
agnostic of the type of this state variable ...".

By the way, what we did before implements what you're saying, but a bit 
better, since we only needed to define the specs once and then include 
them each time. In this case we'd always need to define them at least twice.

Example: we have a behaviour `rabbit_backing_queue': 
https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_backing_queue.erl 
. The types `ack()' and `state()' are specific to the implementation. An 
example implementation is rabbit_variable_queue ( 
https://github.com/rabbitmq/rabbitmq-server/blob/master/src/rabbit_variable_queue.erl 
) implements this behaviour, and defines ack() and state() types, which 
are now unused. Following your suggestion I'd have to re-define the 
15-or so methods in rabbit_backing_queue, which is really undesirable - 
I'd rather just leave things as they are.

Francesco.



More information about the erlang-questions mailing list