Scott Hanselman

.NET 4.1 Preview - New Base Class Library (BCL) Extension Methods - RFC

April 1, '09 Comments [16] Posted in ASP.NET | DLR | Javascript | Learning .NET | Microsoft | Musings | Open Source | PHP | Programming | Python | Silverlight | Source Code | Tools | VB | Web Services | Windows Client | XML
Sponsored By

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

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Wednesday, April 01, 2009 8:02:50 AM UTC
Oh, is it like generic?
Wednesday, April 01, 2009 8:03:35 AM UTC
No, it is like April the 1st.
Alexei
Wednesday, April 01, 2009 8:43:13 AM UTC
It didn't occur to me that this might be an April Fool's until I read "make this important new library Open Source". I'm now questioning my sanity for thinking this might be genuinely useful.
Wednesday, April 01, 2009 9:15:04 AM UTC
After reading the comments, I felt so duh
Wednesday, April 01, 2009 9:15:57 AM UTC
Version 4.1, as in April 1st :)
Wednesday, April 01, 2009 9:34:16 AM UTC
Excellent stuff Scott, I've got a few changes of my own to propose. I've posted about them on my blog: http://blog.vibrantcode.com/2009/04/01/QuantumComputingInNet.aspx
Wednesday, April 01, 2009 10:42:31 AM UTC
i know (or think at least) you're kidding but this might actually be somewhat useful :P you could have a TryGetValue that returns a bool and if its false you have the original value to display in validation errors ;)

perhaps not needed in the core framwork though ;)
Wednesday, April 01, 2009 10:51:26 AM UTC
While you're at it, please suggest to mr Hejlsberg a couple of language extensions too; maybebreak, maybereturn and maybebreakorreturn. These would complement the normal break and return keywords but by introducing a measure of unpredictability; let the runtime decide what to do...
Wednesday, April 01, 2009 11:28:23 AM UTC
I know this is entirely offtopic but I figured your most recent blogpost was the easiest way to get your attention.

Could you please make the code for your BabySmash with MEF project publicly available (i.e. via CodePlex etc.)?

Thanks in advance!
Wednesday, April 01, 2009 12:55:14 PM UTC
It's a good thing you don't do comedy for leaving hum? keep up with the outstanding IT work !!!!
=P
funnier ass
Wednesday, April 01, 2009 1:30:06 PM UTC
@3Fox

Babysmash source code is available, see http://www.codeplex.com/babysmash/SourceControl/ListDownloadableCommits.aspx
Wednesday, April 01, 2009 1:39:28 PM UTC
Oh my god, they're organizing against us.

http://haacked.com/archive/2009/04/01/introducing-stringor.aspx
Wednesday, April 01, 2009 2:30:09 PM UTC
Funny prank ;)
Thursday, April 02, 2009 3:11:37 PM UTC
I don't see this as far-fetched or silly except for the tone of the post.
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.
Sunday, April 05, 2009 11:57:00 PM UTC
A sign oustide a German bed and breakfast reads "Heisenberg May Have Slept Here".
Burton Roberts
Tuesday, April 07, 2009 10:27:02 PM UTC
"If we don't know the type of a string, or we want to leave the string, as a string, longer than usual,"

This doesn't make any sense. Great post Scott, you really had us going.
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.