Using -spec for callbacks when defining behaviours
Sat Mar 20 20:46:44 CET 2010
You make good points (consistently). I'm wondering, and this is
probably amounts to "my input" here, whether further research into
contracts may be an interesting way to go with this. In order to
validate large components, you'd "run them under contract" to check
"Component" is not a terminology i'm fond of, thanks to the stunning
range of meaning assigned to that word; but if you have a "component"
that is sufficiently complex as to require a formalized interface, you
may be better advised to establish a full protocol for it. For sure,
you'd be very ill-advised to rely on static checks and not test it
thoroughly prior to committing to its use by other apps/subsystems/
ps. Whilst HTTP is indeed stateless, it's very interesting to observe
that a considerable amount of effort is put in worldwide every single
day to make it look otherwise!
On Mar 20, 6:50 am, Mikael Karlsson <> wrote:
> Well, I have a vague idea that contracts may be protocols but also
> constraints on arguments (or state data) and that you need to check
> them at runtime (see example on contract check in my reply to Kostis
> earlier in this thread).
> Not all interfaces/protocols carry state, simple client-server non-
> transactional requests (like HTTP), for instance and compile time type
> checking can cover a lot of an interface specificaton, but in order to
> have "everything" in place you probably need to complement with
> contract (run-time) checks.
More information about the erlang-questions