[erlang-questions] Spec is diabolical IMHO

[Steve Davis]

Hi David,

I definitely understand and appreciate that rationale. I would pick a bit at the expectation of coding: {_, State} and not expecting the ignored data to be relevant :).

My counter to that would be that if a function was too hard to understand with regard to return values, then the function itself is likely too big and complex -- and counter to any guideline I have seen. 

Rather than double (or more than double) the size of the code,  and make no mistake, -spec IS CODE (although only used by test tools), it may be more effective to devise boundary contracts similar to JA's intention for UBF-C rather than plastering bug-prone "comments" into the raw source.

Best regards,
/s


On Sep 26, 2012, at 3:27 PM, "David Mercer" <dmercer@REDACTED> wrote:

> 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.
>  
> Cheers,
>  
> DBM
>  
> 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
>  
> <rant>
> 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}
>                                                when
>       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.
>  
> </rant>
> /s
>  
>  

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