"Dealing with uncertainty" - Entity Framework CodeOnly

Question

This is a bit of a strange one but I've just seen something on twitter which kind of baffled me and I'm interested to know more.

Rob Conery tweeted the following a couple of hours ago: Class name of the day: "Maybe<T>". Method of the day: "ToMaybe<T>()". He then went on to offer a Tekpub coupon to anyone who could guess where it came from. He linked to a further tweet which had a clue and from that I worked out that it was Entity Framework Code-Only but while trying to determine the usage someone else answered to which Rob replied ...EF CodeOnly - dealing with uncertainty....

So my question boils down to what exactly is he referring to with uncertainty and how does this fit in to Entity Framework Code-Only?

Answer 1

It's mere speculation on my part, but I would guess that it has to do with the ambiguities that one invariably has to deal with when working with an arbitrary data store with arbitrary table names, arbitrary column names, and arbitrary queries.

I doubt very much that it reflects on the code quality of the Entity Framework in any way.

Answer 2

Maybe<T> is one of typical monads, see e.g. this Wikipedia example. Monads are widely used in functional programming: you definitely know IEnumerable<T>, which is monad as well. The LINQ itelf is sometimes described as "language integrated monads". Few more links:

• "What is monad" @ StackOverflow
• "Functional programming, monads: links" (found my own old post)

Presence of Maybe<T> shows that code quality of the Entity Framework definitely isn't bad: they use well-known concept there, which is described many many times (I suspect there is no ToMaybe<T>() there - there must be ToMaybe<T>(T value) and Nothing, so it is just a Rob's mistake).