Cool Extension Methods for New StringOr

Eilon is a madman. If you ever get the chance to actually meet the guy you’ll see right away that part of his brain is engaged in quasi – dimensional pursuits. The only way that I can possibly get the guy’s attention is to hug him – literally – in a bromosexual way. It’s funny to watch him freak on that.

Anyway – the brain that is Eilon’s announced today a new class to handle typing and type conversion of strings (the bane of us all), which will be available in Futures in some CTP form or another:

Mutation of data types leaves a software developer in an interesting situation if the data was not formatted properly and thus could not be mutated. For example, the string “abc123” cannot be parsed into an integer. Many frameworks deal with this situation by immediately reporting an error condition. That error could be an exception that was thrown or a Boolean value of false to indicate failure. Keeping track of these states can easily introduce uncertainty into an application.

The first class being introduced is the StringOr class. It is a generic class that encapsulates both the original string user input as well as the result of an attempted conversion operation.

This is great stuff and ups the whole Duck Typing thing by a good order of magnitude. You can have your type and eat it too:

If the consumer of this API wants the original value, they can use the StringValue property. Otherwise they can use the OtherValue property, which in this case is the successfully parsed integer.

The API is pretty basic:

StringOr<int> userInput= GetUserInput("Quantity");
string szUserInput=userInput.StringValue;
int intUserInput=userInput.OtherValue;

(Note: Eilon asked that I use the naming you see here. He’s part Hungarian and feels the need to connect with his roots).

Introducing Probably

I’m a big fan of this whole thing. I like Strings, don’t get me wrong – I don’t need no stinkin type-safety. The only thing here is that there’s an element of uncertainty that goes into this whole thing. Eilon, being the Sith that he is, deals in absolutes and decided that there can be only two values possible here: “StringValue” and “OtherValue”. But what about the third option: “Probable Value”? Ahh Yes – SubSonic to the rescue.

Given that I’m working up the final bits on SubSonic 3.0 right now, I’m happy to announce support for this new core feature by way of Extension Method: Probably(). The code looks a bit like this:

The super cool thing here is that you can work with a value that is based completely on the user’s experience at the time of using your application! In a way, you could say that the user experiencing the application would actually define (probably) the type of the method they’re working with!

Duck Typing, you’ve been SERVED.

I love the smell of fresh strings in the morning… it smells like…