Nullable TypeConverter for Silverlight

In Silverlight if you want a property of one of your Controls or Models to be Nullable<T> you will end up with a parser error without a little extra work. The reason for this is that there is no default TypeConverter for Nullable<T> so the parser doesn’t know how to convert the string in the Xaml to the appropriate type. To fix this you simply create your own TypeConverter and apply it to your property.

public class NullableTypeConverter<T> : TypeConverter
    where T : struct
{
    public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType)
    {
        return sourceType == typeof(string);
    }

    public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
    {
        Nullable<T> nullableValue = null;
        string stringValue = value as string;
        if (!string.IsNullOrEmpty(stringValue))
        {
            T converted = (T)Convert.ChangeType(value, typeof(T), culture);
            nullableValue = new Nullable<T>(converted);
        }

        return nullableValue;
    }
}

Then to apply it you simply do the following:

[TypeConverter(typeof(NullableTypeConverter<int>))]
public int? Example { get; set; }

Surprisingly Difficult to Parse a Character

I’ve been working on a custom variant of an OMeta parser for a couple weeks now. It’s coming along pretty well, I think I’ve overcome most of the major hurdles and I’m just trying to go through what I currently have, clean it up and get it to solve some of the edge cases that I need.

Just now I was working on the grammar for parsing a character and realized how hard it really is. It sounds trivial, after all it’s just two single quotes and a character right? Wrong. Here’s my current grammar:

CharacterLiteralToken
    = '\'' '\\' 'u' Hex#4 '\''
    | '\'' '\\' 'U' Hex#8 '\''
    | '\'' '\\' 'x' Hex Hex? Hex? Hex? '\''
    | '\'' '\\' ('\'' | '\"' | '\\' | '0' | 'a' | 'b' | 'f' | 'n' | 'r' | 't' | 'v') '\''
    | '\'' '\u0000'..'\uffff' '\'';

It turns out that you have to be sure to account for a multitude of escape characters as well as escaped Unicode literals. I didn’t want to have to implement this, but you can see the last rule which just matches every character under the sun needed it.

This will match:

  • ‘\u0000’
  • ‘\U00000000’
  • ‘\x0’, ‘\x00’, ‘\x000’, ‘\x0000’
  • ‘\”, ‘\”‘, ‘\\’, ”, ‘\a’, ‘\b’, ‘\f’, ‘\n’, ‘\r’, ‘\t’, ‘\v’
  • ‘a’ …

Next I get to do the string parser… that should be even more interesting.

Dictionary Lookup Chrome Extension

Things are a little slow today and I was tired of not having some type of plug-in for looking up the definition of words while reading so I decided to cook up my own real quick.

 

Give it a shot:

https://chrome.google.com/extensions/detail/eeepadhockifhkeglihhapjdhkcpcfal

PS: You might have to install a beta version of chrome first.

 

It’s pretty basic, you just select some text in the browser and a little book icon shows up in the address bar. If you click it, it will open a new tab for you at dictionary.com with the selected text already searched for. Nice and simple.

 

1[1]

 

While it didn’t take long to do it, I have to admit doing the whole thing in javascript was a less than savory experience. I think I’m spoiled by my static languages.

C# as seen by languages with Type Inference…

via @HamletDRC

tumblr_kvdv7l891W1qz9bgeo1_400[1]

 

Ever since I started playing around with Boo this is exactly how I feel about declaring types for my variables…

C#

IFoo foo = (IFoo)Fetch(arg);

 

Boo

foo = Fetch(arg) as IFoo

 

IFoo only ever needs to be written once on any given line. And if Fetch returned IFoo it wouldn’t need to be written at all. Being explicit is great and all, but being redundant is absolutely not.