[erlang-questions] Spec is diabolical IMHO

David Mercer dmercer@REDACTED
Wed Sep 26 22:27:38 CEST 2012

Since no-one else stepped into the breach, I’ll make a case.


In my view, the –spec is a contract, which (1) is usually written before the implementation as part of your design; and (2) as such, it serves as documentation regarding your intent and usage.


In this case, programmers calling the function should be prepared for both an ok return value and an error.  Without the –spec, the programmer does not know this and may just do a match on {_, State} and then not notice any errors when the function changes.  On the other side, when a maintainer comes along later wishing to modify this function, he understands (1) the function’s intent, and (2) how to signal errors.  He can make whatever changes he wishes to effect new functionality so long as he obeys that contract.






From: erlang-questions-bounces@REDACTED [mailto:erlang-questions-bounces@REDACTED] On Behalf Of Steve Davis
Sent: Tuesday, September 25, 2012 19:38
To: Erlang-Questions Questions
Subject: [erlang-questions] Spec is diabolical IMHO


Can someone who knows better explain how this evil child of -spec:
%% @doc The gen_server code_change/3 callback, called when performing
%% a hot code upgrade on the server. Currently unused.
-spec code_change(OldVsn, State, Extra) -> {ok, State} | {error, Reason}
      OldVsn :: Vsn | {down, Vsn},
      Vsn :: term(),
      State :: #state{},
      Extra :: term(),
      Reason :: term().
code_change(_OldVsn, State, _Extra) -> {ok, State}.
...is not a total waste of too many talented people's time over the more transparent:
code_change(_OldVsn, State = #state{}, _Extra) -> {ok, State}.
...or is spec just a diabolical case of over-engineering that is at once both incredibly onerous and bug-prone justified in the cause of the weaknesses of some ill-designed test tool?
My gut reaction is that if you feel that you NEED TO DO TDD style testing, you should take the time parse the source and not bloat it beyond readability by inflicting conventions on the development of the source that will simply distract and so *cause* the bugs you think that you are testing for.
A better use of developer time would be to enforce documentation of the intention of the function.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120926/f55823c7/attachment.htm>

More information about the erlang-questions mailing list