On 20 April 2016 at 18:09, Greg Keogh <gfke...@gmail.com> wrote:
> Now I'm trying to shrink this down to the smallest possible
> functional-looking code possible
>
On 20 April 2016 at 18:17, Greg Keogh <gfke...@gmail.com> wrote:
> new Action(async () => { var r = await GetStuffAsync("Key1"); updateUI(r)
> }).Invoke();
> new Action(async () => { var r = await GetStuffAsync("Key2"); updateUI(r)
> }).Invoke();
> new Action(async () => { var r = await GetStuffAsync("Key3"); updateUI(r)
> }).Invoke();
>
On 20 April 2016 at 23:37, Thomas Koster <tkos...@gmail.com> wrote:
>
> Umm, are you code golfing now to avoid naming anything? Or are you after
> genuine feedback on functional style in C#?
>
> p.s. Sensible application of functional style in C# is *not* code golfing!
> :)
>
That was an unhelpful and poor choice of words, sorry. Serves me right for
mailing at 11.30pm.
I only mean that I don't think these statements are an improvement or
particularly "functional-looking".
Mostly it's all that duplication. Also, those lambdas and Action delegates
might give the example a functional veneer, but it is only superficial.
None of them are real functions that you can re-use or compose into larger
expressions. I suspect that if you translated this into F#, it would be
imperative-looking.
"new Action(f).Invoke();" is functionally identical to "f();", but the
former churns more heap (modulo some clever JIT optimisation). What were
you hoping for by boxing these statements as closures?
Functional style is not about using more lambdas (although you *might* use
them more as a side-effect). Anonymous things are not very useful, even in
true functional languages. When something has a name (i.e. when you write a
function/method for it), you can re-use, generalise, test, document and
discuss it. Inlining is the compiler's job, not ours.
In my opinion, your first code sample with good old methods was much
cleaner and more in the spirit of functional style. After all, a Task<T> is
just like a Func<T> imbued with cooperative suspend/resume capabilities.
--
Thomas Koster
