Make passthrough/1' and func/1 into a ret_spec`

[horkhe]

introduced two new ret_spec() kinds that are meck:passthrough/0 and meck:func/1 that make the following possible:

%% When
meck:expect(meck_test_module, c, [{[1, 2],     meck:passthrough()},
                                  {['_', '_'], meck:func(fun(A, B) -> {B, A} end)}]),
%% Then
?assertEqual({1, 2}, meck_test_module:c(1, 2)),
?assertEqual({3, 1}, meck_test_module:c(1, 3)),

That comes pretty handy given that you can specify them within meck:seq/1 and meck:loop/1

Besides all ret_spec() aware code was moved to a module of the same name.

[horkhe]

@eproxus can I expect comments today, or I just can go to sleep? :)

[eproxus]

I don't have time to review all of it today anyway, so let's keep in touch later. 😃

[horkhe]

sure thing, but please do not disappear for too long :-)

[horkhe]

I hope we can release 0.8 with all that plus matchers before the end of this year.

[eproxus]

Sounds reasonable. I'll review this as soon as I can, promise. 🙇

[eproxus]

What's the difference between meck_ret_spec and meck_expect? Could they both be merged into the same module perhaps?

[horkhe]

meck_ret_spec specifies how to calculate a value that is returned by an expectation. meck_expect represents an expectation that is defined by a list of meck_args_spec/meck_ret_spec pairs where every pair is akin to a function clause/ So these are two different abstraction though the latter using the former as a building block.

In general I create these different modules not because I just like to have lots of files :-), but because I prefer to have distinct data abstractions with clean API and hidden implementation. I believe that greatly improves readability of the code..

[eproxus]

How about removing meck:func/1 and letting a fun directly have the same effect? Then, if one wanted to have a fun as return value they would have to use meck:val/1 around the fun?

[horkhe]

We certainly can make funs serve as a body of a function but, that would break backwards compatibility. and make another exception in ret spec definition. now any X that you specify derectly is treated as meck:val(X) no exceptions. With you propousal we will have exception from that rule. Which means that users of the meck would need to remember that exception.

So it is you call, but I would recommend to stick with meck:fun. less exceptions from general rules we have the better I think.

[horkhe]

@eproxus Hi Adam, it has been awhile since I provided my answers. So what do you think?

[eproxus]

I usually prefer conciseness in API's, especially for stuff that is often used. I think wrapping funs in meck:val(F) is an okay trade off.

[horkhe]

But what about backwards compatibility? Now if you specify ret-spec as
value (including funs) it is used literally.

Maxim Vladimirsky
Sent from my Nexus
On Dec 12, 2012 11:28 PM, "Adam Lindberg" notifications@github.com wrote:

I usually prefer conciseness in API's, especially for stuff that is often
used. I think wrapping funs in meck:val(F) is an okay trade off.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/90#issuecomment-11305110.

[horkhe]

Ok, I will make that change and let you know when it is ready. Probably
tomorrow.

Maxim Vladimirsky
Sent from my Nexus
On Dec 12, 2012 11:28 PM, "Adam Lindberg" notifications@github.com wrote:

I usually prefer conciseness in API's, especially for stuff that is often
used. I think wrapping funs in meck:val(F) is an okay trade off.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/90#issuecomment-11305110.

[eproxus]

Hmm, so far this has never made it into a proper 0.X release, so I wouldn't worry about backwards compatibility.

[horkhe]

Ok. It also occurred to me that it does resemble more the former
meck:expect(Mod, Func, Fun) syntax. So I will rework processing of fun's
according to you suggestion.

On Thu, Dec 13, 2012 at 2:51 PM, Adam Lindberg notifications@github.comwrote:

Hmm, so far this has never made it into a proper 0.X release, so I
wouldn't worry about backwards compatibility.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/90#issuecomment-11330211.

[horkhe]

Closed as a not extendable pull request. It continues as #91.