Using -spec for callbacks when defining behaviours

[Mikael Karlsson]

On 18 mar, 05:49, Steve Davis <steven.charles.da...@REDACTED> wrote:
> Hmm.
>
> I find myself, having read this discussion, left rather cold and
> wondering: what problem does this idea resolve? I haven't really hit
> any practical issues with using behaviours, or with dependencies on
> include files. Both seem to work pretty well as they stand.

Yes, well as Kostis pointed out they already found violations of the
-specs in the Erlang code, so the problem addressed is quality of code
I guess. You could of course say that since no one seem to have any
bad
experience (yet) of the violations they do not have any practical
impact
anyway.
Include files are OK, but sometimes I feel that they are problematic,
setting include paths right to external libraries etc. I guess if you
look at the problem of that the include files often holds records and
that you may wan't to move away from using records and use "opaque"
types
instead (can give cold wonderings as well :) then I think that
behaviour
modules is a good place to start. Since specs then go into compiled
code,
it is "only" needed that the compiler holds the compiled behaviour
code
in the load path.

> As a coder, I'm concerned that this suggestion (and other forms of...
> type-envy?) may not actually get in the way of what we are trying to
> get done rather than assist it?

I do not think any of the proposed things will be mandatory, but
optional,
you can choose to use them at your own will.

> fwiw, a year ago I would probably have been an active advocate of more
> language support for type constraints, but the longer I spend building
> things using erlang, the more I have come to see things in an entirely
> different light.

I confess I have very ambigous feelings about this, and partly agree,
..but
if opaque types (or abstract data types/patterns) become more frequent
in
Erlang I guess there will be more need for type specifications.

> Just my 2c here of course.
> /s

I will not bet with you on this.

/Mikael