Using -spec for callbacks when defining behaviours
Mikael Karlsson
karlsson.rm@REDACTED
Fri Mar 19 09:59:49 CET 2010
Hi Steve,
On 19 mar, 00:46, Steve Davis <steven.charles.da...@REDACTED> wrote:
> Hi Mikael,
>
> On Mar 18, 6:33 am, Mikael Karlsson <karlsson...@REDACTED> wrote:
>
> > I do not think any of the proposed things will be mandatory, but
> > optional,
> > you can choose to use them at your own will.
>
> For sure, and it's an interesting and useful discussion to have.
Agree.
> > > 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
> > 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.
>
> I'd temper this with the known effective approaches:
> 1) "let it crash"
> 2) apply checks only at the application/system boundary
>
> ..to which I'll add...
>
> 3) beware any form of cruft.
>
> regs,
> /s
OK, a use case maybe.
Suppose you wan't a uniform interface to access SQL databases for
different native database implementations. Similar to jdbc in Java or
PDO in PHP. You know how to implement it in MySQL, but would like to
leave the door open to others to implement it for other dabases
(postgresql,Oracle).
An interface specification is good for the implementors (and for the
end users), and the more support you have from your build and debug
environment the better I would say. In a sense I would say that your
second item concering system boundaries applies here.
Erlang is very efficient to implement applications in and as long as
you roll your own stuff or are within a tight group I think your
points apply, but I would like to argue that for building large
community based infrastructure it is very important to be able to have
useful interface specifications/contracts.
Regards Mikael
More information about the erlang-questions
mailing list