[erlang-questions] Spec is diabolical IMHO

[Daniel Eliasson]

In my experience, a lot of functions perform tail calls in such a way
that it's not immediately clear which types will be returned. Without
specs, it's frequently necessary to start following the code many
levels deep in a branching tree. Exported functions should have specs;
at the very least those intended as an API to other applications
should.

If I can't look at an API function and very quickly understand
i) what type of values I am to pass as arguments, and
ii) what type of values I get in return,
then I have resort to archeology or empirical studies, both of which
are unpleasant.

/Daniel

On 27 September 2012 01:21, Steve Davis <steven.charles.davis@REDACTED> wrote:
> 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
>
>
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>