.NET 4.1 Preview - New Base Class Library (BCL) Extension Methods - RFC
As web programmers, we use a lot of strings to move data around the web. Often we’ll use a string to represent a date or an integer or a boolean. Basically "1" in instead of 1, or "April 1, 2009" rather than a proper ISO-8601 formatted culture-invariant date.
While these strings are flying around via HTTP it's not a huge deal, but sometimes this loose, even sloppy, use of strings can leak into our own code. We might find ourselves leaving the data times as strings longer and longer, or not even bothering to convert them to their proper type at all. This problem is made worse by the proliferation of JSON, and schema-less/namespace-less XML (that I've often called "angle-bracket delimited files" as they're no more useful than CSVs in that point.
.NET 4.0 is pretty much locked down, but version 4.1 still has some really cool "Futures" features that are being argued about. If we don't know the type of a string, or we want to leave the string, as a string, longer than usual, what if we had an class that could be both a string and another type, essentially deferring the decision until the variable is observed. For example:
StringOr<int> userInput= GetUserInput("Quantity");
string szUserInput=userInput.StringValue;
int intUserInput=userInput.OtherValue;
Sometimes you just don't know, or can't know.
This reminds me of a similar, but orthogonal physics concept, that of the Heisenberg Uncertainty Principle. Sometimes you know that an object is a string, and sometimes you know how long it is, but you can’t know both at the same time.
One of my favorite jokes goes:
Heisenberg gets pulled over by the police. The officer asks, “Do you know how fast you were going?” Heisenberg answers, “No, but I know exactly where I am!”
This library doesn't solve THAT issue, with respect to strings, but we’ve got folks in DevDiv working on this and many other metaphysical - and physical - problems as they apply to computer science.
Big thanks to Eilon, who's working hard to get this pushed into the .NET 4.1 Base Class Library. Visit Eilon's blog for more details on this new library, more code, graphics and details on how Intellisense will handle this new case.
Hopefully, someone is working to make this important new library Open Source.
Your thoughts, Dear Reader?
Related Posts
- Rob Conery on StringOr<T> and Duck Typing and the Probably() extension
- Eilon Lipton's RFC and Analysis with Pictures and Code Samples
- Jonathan Carter on the ramifications to String-based User Input
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Jack
perhaps not needed in the core framwork though ;)
Could you please make the code for your BabySmash with MEF project publicly available (i.e. via CodePlex etc.)?
Thanks in advance!
=P
Babysmash source code is available, see http://www.codeplex.com/babysmash/SourceControl/ListDownloadableCommits.aspx
http://haacked.com/archive/2009/04/01/introducing-stringor.aspx
Isn't this the basic concept of Nullable<int>? It's an int or maybe it's not an int. You defer the determination of the type until later. As useful as int? is, I see it as a C-style union struct where you're ramming two unrelated types into one thing. Isn't the essense of Nullable<int> the same as StringOr<int> (or Stringable<int>)?
Please note that I am advocating such a thing. My comparison of Nullable<> to unions was not a complement.
This doesn't make any sense. Great post Scott, you really had us going.
Comments are closed.