Hacker News Reader

Comment by lubutu | Hacker News Reader

Using this approach you would often also need to maintain state about what was requested, using closures or similar to avoid race conditions. Alternatively, Haskell offers the Maybe type, where Nothing means "not found" and Just x means "found x". Using a callback seems more prone to disaster than just encoding the possibility of null into the type system.

View on HN

C# offers this via Nullable<T>:

  Nullable<int> someNumber = foo.TryAndGetSomeNumber();
  if(someNumber && someNumber.HasValue)
    doSomething( someNumber.Value );

Why don't you use int? rather than Nullable<int> - aren't they equivalent?

The point is, all values of the int are available. Null is stored somewhere outside the underlying int.

It was just a question about the syntax used - why type Nullable<int> when there is direct syntactical support in C# for nullable types - in this case you could simply type int? rather than Nullable<int>

At the very least Nullable<T> is a lot friendlier to search than T? if you want to learn more on the subject.

not everyone is familiar with C#, and Nullable<int> conveys better meaning in writing to that kind of audience.

int? is syntactic sugar for Nullable<int>, which didn't seem worth getting into :-)

if(someNumber && someNumber.HasValue)

You still have to remember to do this check. Will the compiler complain if you use someNumber.Value without checking that its valid first? If not, then its not really the same thing.

The point of Haskell's Maybe is that the compiler will make sure that you take both cases (that there is a value and that there isn't a value) into account (because to extract the value you must pattern match and pattern matches must be exhaustive, otherwise you get a compile error).

Eh, that's putting it a little too strongly. Haskell is a nice language, but it still doesn't protect you from all your mistakes. The easiest way to extract the value in Haskell is fromJust, which simply errors if no value was returned. I do agree that Haskell makes it more natural, though.

The compiler won't, no - but many/most developers use static analysis tools like ReSharper which WILL tell you that you have a possible NullReferenceException there if you don't check it.

More idiomatic C# might be:

  int result;
  if (foo.TryAndGetSomeNumber(out result))
    doSomething(result);

There might also be a foo.GetSomeNumber() that returns an int or throws on failure.

[fixed formatting]

I disagree that your example is more idiomatic. Maybe pre-3.0...

Today is TCO/TCE day at HN! Haskellers learn "Dont' tail call, map/filter/fold"

re: haskell: Unfortunately or otherwise, due to influx of devs,the nomenclature has gotten mangled re Maybe/Either and all the other things that (data) can do:

- ADT used to denote abstract data types,

- Algebraic data types used to signify sum (e.g. Maybe and Either) and product (e.g. record) types, I think many people use it for only sum types now (hard to quantify my impressions of current usage, tho)

Scala has the Option/Some type, IIRC based on Haskell's Maybe, where it's used as: Option(int), and then you check the return for None or Some(int). The compiler should catch when you forget to cover the None case.

Here's a good little tutorial: http://www.codecommit.com/blog/scala/the-option-pattern

Reply on news.ycombinator.com