[erlang-questions] [Dialyser] Type parametrized behaviours

[Stavros Aronis]

Ok, I understand your original approach now. It is indeed clever and 
reduces duplication.

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. 

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.

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.

Stavros

On Tuesday, April 24, 2012 10:27:18 PM UTC+2, Francesco Mazzoli wrote:
>
> 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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120424/6ea0225e/attachment.htm>