The String or the Cat: A New .NET Framework Library

For years applications have been built that accept user input. Most user input starts out as a string. Strings are a universal representation of arbitrary data coming into a computer. However, most data does not remain as a string for very long. User input often ends up getting parsed or converted into another data type, such as an integer, Boolean value, or a date.

The concepts presented here are based on a thought experiment proposed by scientist Erwin Schrödinger. While an understanding of quantum physics will help to understand the new types and APIs, it is not required.

clip_image002

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.

StringOr<TOther>

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.

namespace System.QuantumEntanglement {
    public class StringOr<TOther> {
        public StringOr(string stringValue, TOther otherValue);

        public string StringValue { get; }
        public TOther OtherValue { get; }
    }
}

The usage of the StringOr class is quite simple. An API that wishes to return data that might not have been parsed successfully can use the StringOr class to represent the dual state of its return value.

For example, a typical application might have a TextBox for entering an integer quantity:

clip_image004

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 following diagram illustrates the dichotomy with a scenario familiar to many physicists:

clip_image006

SchrodingOr<TDead, TAlive>

The second class being introduced is the SchrodingOr class. It is similar to the StringOr, but with a distinct difference regarding its states. The SchrodingOr can represent any two data types: It is not restricted to one of the types being a string.

namespace System.QuantumEntanglement {
    public class SchrodingOr<TDead, TAlive> {
        public SchrodingOr(TDead dead, TAlive alive);

        public TAlive Alive { get; }
        public TDead Dead { get; }
    }
}

The usage of the SchrodingOr class is also similar to the StringOr. An API that wishes to return data that might be either of two data types, but never both data types at the same time, can return a SchrodingOr. The following code sample demonstrates a case where an API returns a value that can be either a bool or a DateTime.

clip_image008

Depending on the effects of quantum mechanics one of the two properties will return its value, while the other will throw a HeisenburgException. As before, the following diagram illustrates the dichotomy of the two possible values:

clip_image010

System.QuantumEntanglement Community Technology Preview

While the new .NET Framework library is still in relatively early stages of development, the team has decided to release a sneak preview to get feedback from our users. The link below contains the full source code for the new library, as well as unit tests that demonstrate proper usage of the libraries.

Please send all questions, comments, and suggestions to string.or@microsoft.com.

Many thanks,

The .NET Framework Quantum Mechanics Team

20 Comments

  • Very interesting stuff! I can see a lot of practical applications of this. For example, in ASP.NET MVC, incoming data goes through the model binder, which wouldn't necessarily know what type the input data was supposed to represent (or even what culture settings should be used to parse the string value) until it is later "observed" by an action method and its type/culture becomes fixed.

    Would it be possible to use this technology to replace WCF/.NET remoting too? Assuming that you can put two objects into a "quantum entangled" state, you could then transmit one of them across the wire, keeping the other locally. Later, any changes made to your local object would instantly cause effects on the remote object, no matter how far away it now is, and even if no network connectivity was available. This would be much faster than any of the current forms of RPC, and wouldn't require the objects to be serializable.

    Can't wait for .NET 4.1, it's going to be awesome!

  • Awesome..... A change from orthodox programming will be well received.

  • I love pink ponies and unicorns day :) ...

  • Interesting stuff.

  • You should pay me in case you release such a framework or I will sue Microsoft because of copyright infringement.

  • Looks promising, but there is no actual type conversion for now. Will it be in BCL itself?

  • Kudos to you and Scott for making this better by putting it out on April 1st ;)

  • Nice April 1 Joke "The .NET Framework Quantum Mechanics Team" :)

  • Nice one! but HeisenburgException ought to be HeisenbergException.

  • This is BS. This is the test you want to perform:


    StringOr userInput = "abc123";
    Assert.AreEqual(123, userInput.OtherValue);

  • I'm anxiously awaiting the release of the QLR! :)

  • I'd discourage this cute code in production systems. It would not pass our code review/code quality/code security requirements.

    StringOr class fails the requirement that well engineered systems do not delay exception handling, ignore errors until later or allow an error to be resurrected multiple times (i.e., be each object that calls StringOr to get an integer when StringOr is not an integer "123abc").

  • Eilon,

    The solution you describe can be easily handled with a generic facility for Tuples - among other things this will help aligning the BCL with F# as a first class citizen! It will also help reduce the semantic load of output variables.

    If my petition is not successful then I would ask to modify the definition of StringValue to return the remainder of the string after partially parsing the integer value, i.e.
    if userInput = "123inches"
    then userInput.OtherValue -> 123
    and userInput.StringValue -> "inches"

    You have to decide on the representation of complete parsing failure.

    This will allow us to do much more elaborate input parsing by combining simple parsers (parameterized by the type of OtherValue) using Linq techniques to emulate monadic parsers.

    Just google for Parsec.

    Regards,

    Dimitris Foukas

  • What would the interface look like for DoppelgangOr?

  • @Erwin S. Let it go man, the cat is dead... or is it? Happy 1st

  • i like both the class.. and its very clear that i will be using this a lot in my future projects. But what's with the HisenburgException. Does it have to do anything with "Hisenburg's Uncertainity Principle" for location of an electron ?

  • Anyone who took this seriously, despite preceding references to April Fool's in the comments, should think about a career change to turnip picking :)

  • I dont understand the new feature. What the difference? What the advantage over, for example, int.Parse the StringOr has? In failure case, what the StringOr behavior?

    A simple and practical example (a comparative piece of code also, please)?

  • Hi,

    Can you please tell some practical usage of these functions ?

    Thanks,
    Thani

  • Four negatives in an extension method makes me antsy.

Comments have been disabled for this content.