Using -spec for callbacks when defining behaviours

[Mikael Karlsson]

Yes, I think that contract checkers that are "pluggable" at validation
time is a good way to go, and if you find a standardized way or
"formalized" pattern to put it in the process of Erlang code making
the better. Joe Armstrongs UBF contracts is a good example. I agree
that you should not rely on static checks, but on the other hand they
are a good first check and especially for Erlang I think you can catch
errors that you would later at run-time (Dialyzer do find errors).
Best Regards
Mikael

On 20 mar, 20:46, Steve Davis <steven.charles.da...@REDACTED> wrote:
> Hi Mikael,
>
> 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
> their behavior.
>
> "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/
> components.
>
> Best regards,
> Steve
>
> 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 <karlsson...@REDACTED> 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.