odytrice/operation

Railway Oriented Programming in C#

operation's Issues

No Change Log

It is important to have a change log so that people can know what has changed.

"Throw" function seems misnamed

This is just a note on the API method "Throw", which is documented as:

Unwraps the Operation if Successful and Throws an Exception if an Operation Fails

The function name "Throw" implies that the method always throws, or throws for a failed operation (It looks like this is how it used to work?). However the method also returns the value of the operation on success - not really what it says on the tin.

Why not rename the function to "Unwrap"? That's the word you're using in the documentation and it seems to fit the actual use-case somewhat better as well.

Exception is lost when UnWrap is called

The original exception is lost whenever Unwrap is called. It throws a new Exception

Simple Constructors for Success and Failed States

I think using Operation.Create for Creating Successful and Failed Operations is a bit heavy handed as you must allocate an Entire Delegate.

We could have something like Operation.Fail(string message) and Operation.Success(), Operation.Success<T>(T result) methods for both Operation and Operation<T>

NOTE- Moving Forward Operation and Operation<obj> where Operation<obj>.Result = null are treated as the same thing

Create should take a Delegate that Returns Operation

Operation.Create should take a Delegate that Returns Operation and Unwrap it Implicitly. Instead of Throwing it explicitly

Operation.Create(() => {
    //Do Some Operations
    var doStuff = SomeOperation(param1, param2)
    return doStuff;
});

Support Idiomatic Operators

I think the Next Operator is kind of misleading and it's doing too much. So for version 1.1. I am proposing that it supports the classic
Map
Bind
Fold - Needs to be redefined
Collect
Unit instead of Create
So that it is using the Idiomatic Functional Operators
The Existing Operators will still remain only that they will call the underlying Operators

Add Catch Operator for On Error Cases

Add an OnError Operator something like

operation.OnError(e => ());

That way you don't need to explicitly check before you do something on the Error

Operation<IEnumerable> returns IEnumerable

While using query expression syntax and interacting with an Operation<IEnumerable>, the result of the expression is an IEnumerable instead of Operation<IEnumerable> i.e.

var stringOps = Operation.Create(() => new List<string> { "Some", "String" });
var result = 
      from strings in stringOps
      from strng in strings
      select strng +" "+ "Appended String";      

"result" is an IEnumerable instead of Operation<IEnumerable>