Sorry, I'm confused. Initially you wrote:
"For consistency, I think it should actually capture the value, and
maybe we
can add a .LazyEvaluation() after the expectation if you want
difrerent
behavior?"
Just so we're totally clear, what we're talking about is a captured
outer variable in a closure. For the most part, I like the way Moq
handles these currently. It makes methods like Callback() extremely
easy to use - you generally want a callback delegate to affect the
outer scope. I think of closures as lazy-evaluated, as the captured
variable's value is accessed when the delegate is invoked, not when
the delegate is created. So to me, the default behavior of Moq (when
lambdas are used) is lazy evaluation. Please correct me if I'm
mistaken.
(I'm not trying to be pedantic, just precise. I'm having to cross-
reference Skeet's "C# in Depth" to get the terminology right.)
Really, the only time I've run into surprises with Moq's use of
lambdas is with out/ref parameters. My personal feeling is that adding
LazyEvaluation() or ImmediateEvaluation() would only confuse people
(hey, it confused me), and that changing the current behavior for
other methods (Callback(), Returns()) would be detrimental.
One possibility you might consider is adding a different syntax for
setting out parameters. The current syntax confuses ReSharper - it
thinks the initial value assigned to the variable used with the out
parameter is never used, and many programmers would also suspect this.
I personally feel that this is one of the few places where Rhino Mocks
syntax is clearer, with .OutRef("value") used to set the out parameter
value. It's not like Ayende hasn't borrowed from you before... ;-)
Anyway, my two cents.
Thanks!
Bill Sorensen
On Oct 9, 8:14 pm, "Daniel Cazzulino" <
dan...@cazzulino.com> wrote:
> but then that would mean that by default we'd do lazy evaluation? that's the
> opposite of what we do now...
>
> which one do you think is the most obvious behavior? (remember that for
> Returns(...) we cannot do lazy evaluation unless you use lambda version,
> because the compiler would resolve that and just call our API with the
> value, and we don't get an expression at all...
>