3 ms·

I don't love OneOrMore<T> It's trying to generalize - we might have exactly one T, fine, or a collection of T, and that's more T... except no, the collection m

I don't love OneOrMore<T> It's trying to generalize - we might have exactly one T, fine, or a collection of T, and that's more T... except no, the collection might be zero of them, not at least one and so our type is really "OneOrMoreOrNone" and wow, that's just maybe some T.

CharlieDigital 7mo ago
`OneOrMore<T>` was an example of using `union` types. You are free to call it `public union Some<T>(T, IEnumerable<T>)`
- gf000 7mo ago
  But now you can only call methods that are available for both T and IEnumerable<T>, you have no way of knowing which it actually is. (You would know if it were sum types)
rafaelmn 7mo ago
> OneOrMoreOrNone So IEnumerable<T> ? What's up with wrapping everything into fancy types just to arrive at the exact same place.
merb 7mo ago
OneOrMore is more or less an example from the functional world. i.e.: https://hackage.haskell.org/package/oneormore https://hackage.haskell.org/package/oneormore or scala: https://typelevel.org/cats/datatypes/nel.html https://typelevel.org/cats/datatypes/nel.html it's for type purists, because sometimes you want the first element of the list but if you do that you will get T? which is stupid if you know that the list always holds an element, because now you need to have an unnecessary assertion to "fix" the type.
- dasyatidprime 7mo ago
  The NonEmptyList in Cats is a product (struct/tuple) type, though; I assume the Haskell version is the same. The type shown in the blog post is a sum (union) type which can contain an empty enumerable, which contradicts the name OneOrMore. The use described for the type in the post (basically a convenience conversion funnel) is different and makes sense in its own right (though it feels like kind of a weak use case). I'm not sure what a good name would've been illustratively that would've been both accurate and not distracting, though.
  - merb 7mo ago
    Well you are right of course, I just wanted to explain what they wanted to show. Of course the type would be wrong if the second entry in itself is an empty list. I just wanted to explain the reasoning what they tried to accomplish They could’ve done the Either type which would’ve been more correct or maybe EitherT (if the latter is even possible)
    - dasyatidprime 7mo ago
      I don't think they were trying to accomplish the same thing as the Scala/Haskell version; these are just two completely different things that happen to share a name because the blog post gave the example a name that is confusing when read literally. The purpose of the Cats version is “there is always a head element”. The purpose of the union in the blog post is more like “this can be a collection, but many callers will be thinking of it as a single element, so don't put the burden on them to convert it”. I do think it's a weak case for them in a type theory sense (I would tend to position that kind of implicit conversion elsewhere in the language), but I can also see it being motivating to a large class of developers… … wait, I've made a different mistake here while trying to explain the difference, haven't I? I was describing it as a sum type, but it's not really a sum type, it's really just set-theoretic union, right? Which also means OneOrMore is unsound in a different way because it doesn't guarantee that T and IEnumerable<T> are disjoint; OneOrMore<object> initialized from [x] will always return [[x]] from AsEnumerable, won't it? If I'm interpreting the switch expression correctly and the first case predominates, since a list is-an object? I don't have a test setup handy; someone with actual C# experience, please tell me whether that's correct or whether the compiler signals an error here or something…
paulddraper 7mo ago
I went to prove you wrong… And you’re exactly right. It’s not “one or more.” It’s “one or not one.” Need two or not two.
- recursive 7mo ago
  Hotdog or not hotdog.
layer8 7mo ago
> so our type is really "OneOrMoreOrNone" If I understand correctly, it’s actually OneOrOneOrMoreOrNone. Because you have two different distinguishable representations of “one”. The only reason to use this would be if you typically have exactly one, and you want to avoid the overhead of an enumeration in that typical case. In other words, AnyNumberButOftenJustOne<T>.
qingcharles 7mo ago
I have the same gripe about IsNullOrWhiteSpace which is basically an extension to IsNullOrEmpty, so it really should be named IsNullOrEmptyOrWhiteSpace.

CharlieDigital 7mo ago

`OneOrMore<T>` was an example of using `union` types. You are free to call it `public union Some<T>(T, IEnumerable<T>)`

gf000 7mo ago
But now you can only call methods that are available for both T and IEnumerable<T>, you have no way of knowing which it actually is. (You would know if it were sum types)

rafaelmn 7mo ago

> OneOrMoreOrNone So IEnumerable<T> ? What's up with wrapping everything into fancy types just to arrive at the exact same place.

merb 7mo ago

OneOrMore is more or less an example from the functional world. i.e.: https://hackage.haskell.org/package/oneormore https://hackage.haskell.org/package/oneormore or scala: https://typelevel.org/cats/datatypes/nel.html https://typelevel.org/cats/datatypes/nel.html it's for type purists, because sometimes you want the first element of the list but if you do that you will get T? which is stupid if you know that the list always holds an element, because now you need to have an unnecessary assertion to "fix" the type.

dasyatidprime 7mo ago
The NonEmptyList in Cats is a product (struct/tuple) type, though; I assume the Haskell version is the same. The type shown in the blog post is a sum (union) type which can contain an empty enumerable, which contradicts the name OneOrMore. The use described for the type in the post (basically a convenience conversion funnel) is different and makes sense in its own right (though it feels like kind of a weak use case). I'm not sure what a good name would've been illustratively that would've been both accurate and not distracting, though.
- merb 7mo ago
  Well you are right of course, I just wanted to explain what they wanted to show. Of course the type would be wrong if the second entry in itself is an empty list. I just wanted to explain the reasoning what they tried to accomplish They could’ve done the Either type which would’ve been more correct or maybe EitherT (if the latter is even possible)
  - dasyatidprime 7mo ago
    I don't think they were trying to accomplish the same thing as the Scala/Haskell version; these are just two completely different things that happen to share a name because the blog post gave the example a name that is confusing when read literally. The purpose of the Cats version is “there is always a head element”. The purpose of the union in the blog post is more like “this can be a collection, but many callers will be thinking of it as a single element, so don't put the burden on them to convert it”. I do think it's a weak case for them in a type theory sense (I would tend to position that kind of implicit conversion elsewhere in the language), but I can also see it being motivating to a large class of developers… … wait, I've made a different mistake here while trying to explain the difference, haven't I? I was describing it as a sum type, but it's not really a sum type, it's really just set-theoretic union, right? Which also means OneOrMore is unsound in a different way because it doesn't guarantee that T and IEnumerable<T> are disjoint; OneOrMore<object> initialized from [x] will always return [[x]] from AsEnumerable, won't it? If I'm interpreting the switch expression correctly and the first case predominates, since a list is-an object? I don't have a test setup handy; someone with actual C# experience, please tell me whether that's correct or whether the compiler signals an error here or something…

paulddraper 7mo ago

I went to prove you wrong… And you’re exactly right. It’s not “one or more.” It’s “one or not one.” Need two or not two.

recursive 7mo ago
Hotdog or not hotdog.

layer8 7mo ago

> so our type is really "OneOrMoreOrNone" If I understand correctly, it’s actually OneOrOneOrMoreOrNone. Because you have two different distinguishable representations of “one”. The only reason to use this would be if you typically have exactly one, and you want to avoid the overhead of an enumeration in that typical case. In other words, AnyNumberButOftenJustOne<T>.

qingcharles 7mo ago

I have the same gripe about IsNullOrWhiteSpace which is basically an extension to IsNullOrEmpty, so it really should be named IsNullOrEmptyOrWhiteSpace.