Replies: 2 comments 1 reply
-
I agree that this could be useful. I use (x,xs) as workaround to get this compile time safety which is compatible with current
You can use this with structs to get rid of null ref errors (and default constructor in classes).
Links: |
Beta Was this translation helpful? Give feedback.
1 reply
-
I think the using LanguageExt;
using LanguageExt.ClassInstances;
using LanguageExt.ClassInstances.Pred;
using LanguageExt.ClassInstances.Const;
using LanguageExt.TypeClasses;
using static LanguageExt.Prelude;
public struct ValidNonEmptySeq<T> : Pred<Seq<T>>
{
public bool True(Seq<T> value) => value.Count() > 0;
}
public class NonEmptySeq<T> : NewType<NonEmptySeq<T>, Seq<T>, ValidNonEmptySeq<T>> { public NonEmptySeq(Seq<T> seq) : base(seq) { } }
var testPass = NonEmptySeq<string>.New(Seq1<string>("Item"));
var testFail = NonEmptySeq<string>.New(Seq<string>()); |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am a big fan of LanguageExt and I am a big fan of designing with types, especially making illegal states unrepresentable (see here). Recently I had a couple of times the problem that I needed to have a collection of items that must have at least one item in the collection. An empty collection was invalid. I had to permanently check whether the collection is not empty which is a nuisance. But what is worse, what should I do when I encounter that condition? Usually when you get an empty list when you expected a non-empty list, the problem happened in a completely different location.
Suppose you have an order processing object that requires at least one item in the order. When that order processing object receives an order object without at least one item in it what should it do? How is it supposed to handle that situation gracefully? Most probably somewhere else something went wrong and it would be so much better to detect that problem exactly there and not further down the line in the order processing.
The more I thought about it, the more examples I found where this would be very useful. If your domain requires to have at least one item it is so much more convenient when you have a type NonEmptySeq that guarantees exactly that. No error checking for emptiness needed. No extra test needed.
Other advantages are: when you try to get the first or last element it is guaranteed that you get one. Furthermore, min(), max(), average() etc. will also always work without having to specify a default value.
Therefore my question: wouldn't a NonEmptySeq be a nice new member for the LanguageExt immutable collections?
I would love to design my Order class something like that:
class Order { private NonEmptySeq<OrderItem> _orderItems; }
This would make the illegal state of having no order item impossible. I quite like that design.
So, what do you think about that?
Regards,
Dirk
Beta Was this translation helpful? Give feedback.
All reactions