Back to Questions
1.3k
views6
comments
Conditional Construct
f#functional

I'm wondering if there is a functional construct or pattern out there that is similar to this:

public static bool Conditional<T>(this T value, Func<T, bool> predicate, Action<T> action)
{
if (!predicate(value)) return false;
action(value);
return true;
}

I know this example is in C# but I just happened to be writing C# code when I needed this. :) I'm also curious as an F# coder as well. Basically what I want is to do something with a value if a predicate returns true and then return the value of the predicate to do further processing:

List<object> record = null;

if (!GetRecord().Conditional(
r => r != null,
r => record = new List<object>(r))) return false;

I'm trying to avoid this type imperative logic (Which seems to pop up hear and there):

object[] values = GetRecord();

if (values == null) return false;

List<object> record = new List<object>(values);

Anyways, I don't want to reinvent the wheel if there is already a functional pattern or construct out there that handles this.

TIA,

m

.

For the specific example, a better way could to be to return None when the object array is null, and Some of List when it is not. Maybe use something like:

(sorry for the wrong indentation, for some reason I cannot get it right)

1
2
3
4
5
6
7
8

let asList (nullableArray : 'a []) = 

    match nullableArray with

    | null -> None

    | x    -> Some (x |> Array.toList)

And then:

1
2

let record = asList getRecord
By on 3/11/2010 8:38 AM ()

Thanks for all the responses! I'm gonna play with it a bit more.

By on 3/18/2010 2:26 PM ()

I'm trying to avoid this type imperative logic (Which seems to pop up

hear and there):

1
2
3
4
5
6
7
8
9
10

 
object[] values = GetRecord();


if (values == null) return false;


List<object> record = new List<object>(values);

How about the dear old ternary conditional (if the main computation is pretty short)?

1
2
3
4
5

 
object[] values = GetRecord();


return (values == null) ? false : List<object> r = new List<object>(values), foo(r), bar(r), true;

-- Rest of the post removed... just a late night off-topic digression. --

By on 3/10/2010 1:14 PM ()

After some more thought in the shower... **

I think the ugliness in that pattern comes from the 'impurity' of the computation you're carrying out.

Basically if you just had:

1
2
3
4

object[] values = GetRecord();


return (values == null);

all would be nice.
But you inject another computation into it, with potential side effects that have nothing to do with the actual result of the function (method):

1
2
3
4
5
6
7
8

object[] values = GetRecord();
if (values == null) return false;


have_side_effects(values);
return true;

And for this pattern, what you came up with can't be improved, I think.

But at this point I would change things around, to get rid of the pattern itself. How about changing the contract of GetRecord() as to return a 'smoother' set of possible values (maybe an empty array instead of null, that can be treated as a normal case afterwards)? In the end the bad behaviour of GetRecord() is what is causing the damage here.

Feels like there should be some theoretical work out there on this stuff...

<sub>** I'm a real geek (get the reference?).</sub>

By on 3/10/2010 1:50 PM ()

I don't think the syntax you have for the true condition is legal AFIAK in C# 3.0 or 4.0 (Although if it is that would be an interesting approach):

[link:msdn.microsoft.com]

The code after that logic is a bit more involved anyways.

One of the reasons I didn't go with the ternary operator is I'm trying to avoid having to set an intermediary variable somewhere (The value returned by GetRecord()).

By on 3/10/2010 1:39 PM ()

I don't think the syntax you have for the true condition is legal AFIAK in C# 3.0 or 4.0 (Although if it is that would be an interesting approach):

You might be right there... was that C++ only? Damn.

By on 3/10/2010 2:06 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper