Blogger & HTML

Blogger blows at letting me post with HTML. If I paste HTML into the "Edit Html", which I have to do in order to show any code (from that Copy to HTML VS Plugin), it adds all kinds of spacing. It's really pissing me off. Much longer and I gotta get the hell out of here. Writing blog posts is hard enough...why should the engine make it harder? Guys, instead of crafting little features, why don't you let me paste raw HTML without messing with it?

Generic Gripes

Two things:

1. If you have a generic class with type parameter constraints, those contraints are not inherited automatically in sub types. Ex:

class Foo<T> where T: IConvertible
{
}

class Bar<T> : Foo
{
}

Don't work. You have to put the "where T: IConvertible" on Bar. Doesn't make sense to me.

2. There is no way to loop through a bunch of generic instances with different type parameters and access members that don't have type parameters anywhere in their signature. Ex:

If you have some lists, like:
List<int> = GetInts();
List<strings> = GetStrings();

You can't reference them with just List<> or List<?> or something. While obviously
you can't access the Add, Insert, indexer, and whatever else has the generic type in it. But it would be really convenient if I could access things that don't use it, like Count.

It would be cool to be able to do something like this:

using the two lists above:

List<List<?>> lists = List<List<?>> (ints, strings);

foreach( List<?> currList in lists )
{
int count = currList.Count;//Add would not be available. But Clear would.
}

In the List case, IList makes it possible to loop through some lists and get the Count. So maybe that's a bad example. But imagine you make your own sweet generic class, and want to access some generic-agnostic member, like the HasValue property of Nullable<T>. Then you have to implement an interface or derive from a base class that isn't generic.

I understand why that's not possible today and that it would be difficult to allow. However, it's not impossible and would be nice.

That's all. Very granular crap. Nice weather today.

Download HTTP Resource Without Browser

Today I saw a Silverlight video player that I liked. I wanted to see its source XAML. I got the link (http://www.asp.net/SilverlightPlayer/xaml/videoplayer.xaml). But when I put it into IE or FireFox, I got an error because the browser tries to load it using WPF. Anyway, I kept trying and couldn't figure out how to just download the xaml. If there is a shortcut (which I'm sure there is), I'd like to know.

In the meantime, I wrote a small console app that downloads some url and saves it to a local file. It's only a few lines. Create a new console app and use the following code:

class Program

{

static void Main(string[] args)

{

string uri = args[0];

string filePath = args[1];

byte[] bytes = (new WebClient()).DownloadData(args[0]);

File.WriteAllBytes(filePath, bytes);

}

}

That's it. Using that I was able to get my xaml. Gotta love that .net framework!

Unneccessay EventArgs

Disclaimer: I am not actually doing this now and it's just something to think about and is probably just an obsessive detail. While many say unnecessary or premature optimization is the root of all evil, still, as responsible programmers, we need to keep performance in mind whenever we do things. And while this example may be frivolous, it shows a pattern you can use in other, more important scenarios.

I'm sure you all would agree that the unnecessary creation of objects is not good. Wasting is something we should try to avoid. For example, wouldn't it strike you as wrong to create EventArgs objects for events that are never raised?

Take this code, which is a basic event to alert the application code when a user signs in. The event args gives the developer some more info about the user who logged in:

internal class SigninManager

{

public event EventHandler<SignedInEventArgs> SignedIn;

protected virtual void OnSignedIn(SignedInEventArgs e)

{

if (SignedIn != null)

SignedIn(this, e);

}

private void PerformSignIn()

{

//work work work

string userName = "blah";

//work work work

SignedInEventArgs args = new SignedInEventArgs() { UserName = userName };

OnSignedIn(args);

}

}

public class SignedInEventArgs: EventArgs

{

public string UserName { get; internal set; }

}

Note I'm using some C# 3 features, but this could be done with a prior version with not much work.

In OnSignedIn, you'll notice the event will never get invoked if Fooing is null. The event is only for informational purposes to outside code. If I wanted some feedback, such as a Handled property, things might be different. But I just want to tell application code that "hey, this person logged in."

If no outside code ever handles SignedIn, I am creating the SignedInEventArgs without ever using it. What I would prefer is that the event args get created only if they are needed. But I want to keep my code pretty much the same. I want to keep my OnSignedIn there so I can override it in a sub class. And I don't want to fool with event logic in PerformSignIn. What I need is "lazy instantiation", where the event args only get created if needed.

While there are several approaches, I have a pretty elegant one: use delegates. I will use lamda expressions in my code, although anonymous delegates would work fine. Check this out:

public delegate TEventArgs EventHandlerCreator<TEventArgs>();

internal class SigninManager

{

public event EventHandler<SignedInEventArgs> SignedIn;

protected virtual void OnSignedIn(EventHandlerCreator<SignedInEventArgs> argsDelegate)

{

if (SignedIn != null)

{

SignedIn(this, argsDelegate());

}

}

private void PerformSignIn()

{

//work work work

string userName = "blah";

//work work work

OnSignedIn( () => new SignedInEventArgs() { UserName = userName } );

}

}

public class SignedInEventArgs: EventArgs

{

public string UserName { get; internal set; }

}

Now, instead of passing the event args object I created, I pass a delegate that's able to create the args when invoked. So the OnSigningIn takes that delegate and only creates the args if the event is handled. If it is invoked a million times, we've saved a million objects :).

I think the code is pretty straightforward. Lamda expressions and generics make "lazy instantiation" something that's practical to acheive and maintain. Again, this could be applied to different, more meaningful situations. Regardless, it's pretty nice.