Dynamic LINQ Expression Predicates

I searched high and low for code that explained how to create dynamic LINQ queries.  Specifically, all I really needed where’s a where filter.  No need for sorting or grouping.  Anyway, I finally ran across this wonderful article with a PredicateBuilder extension class.  Works like a charm.  Thanks, Joseph Albahari.

Technorati Tags: LINQ, .NET, C#

Read Full Post »

Live vs. Google

OK, this is annoying.  I use Google Reader to keep up with my RSS feeds.  I live and die by the keyboard shortcuts.

Today, Windows Live came out with three new betas: Writer, Messenger and Mail.  I installed all three of them.

No, in Google Reader, if I change tabs (in IE) I’ll immediately lose keyboard shortcuts.  Worse, even if I don’t change tabs, eventually keyboard shortcuts will stop working.  The only fix is to refresh Google Reader (annoying fix, since doing this loses the context of where I’m currently at in reader).  It has to be an IE addon from one of the three Live services that’s causing this. 😦

If/when I figure out which, I’ll leave a response here so if anyone else runs across this issue they’ll know what the culprit is.

P.S.  Love the new Live Writer.  Just wish I could use it on our SharePoint blogs (complains that the MetaWeblog API isn’t turned on).

Update:  OK, it appears this one isn’t caused by any of the Live betas.  I (and others) receive the same problems on machines that have none of the betas installed.  It was just a "happy" coincidence that this problem started to occur at (roughly) the same time.  So, I have to assume this is something that Google Reader has recently broken.

*sigh*  I REALLY hate that I can no longer reliably use the shortcut keys.  Google Reader is sooooo much less fun to use when I have to mouse around to read posts.  It drastically slows down my ability to read through content. 😦

 

Technorati Tags: Google Reader

Read Full Post »

Vote for lamest new feature in C# 3.0

Automatic Properties.  Lame.  Very lame.

Reading comments on various blogs indicates this is the feature most people seem to be most excited about.  Which is depressing.  Every other language feature being added has me excited, while this one doesn’t.  Not at all.  In fact, I doubt I’ll ever use it, and any code that I find that does use it will immediately be suspect by me.

Here’s some example code:

class Foo
{
	public string Bar { get; set; }
}

class Program
{
	static void Main(string[] args)
	{
		Foo foo = new Foo();
		foo.Bar = "Baz";
		Console.WriteLine(foo.Bar);
	}
}

This "saves" me from having to write this portion of the code in this way:

class Foo
{
	private string bar;
	public string Bar
	{
		get { return bar; }
		set { bar = value; }
	}
}

The problem is, I pretty much never, ever, write code like that above.  This blog post suggests that the above is useful for databinding reasons.  My very first thought about that is, if databinding can’t handle fields (it can’t), don’t you think it would make more sense to "fix" databinding so that it can, rather than add this syntactic sugar for that?  My second thought is, no, even that would be a mistake, and that’s at least part of the reason I never have code that looks like that above.

Huh?  What the heck is this crackpot talking about?

See, when databinding, I expect my UI to update in response to changes to the data model.  This means INotifyPropertyChanged or other mechanisms will need to be employed any time the data changes, and you can’t do that with automatic properties that expose a public setter.  That leaves one minor interesting variation that I could see someone using under rare circumstances:

class Foo : INotifyPropertyChanged
{
	public string Bar { get; private set; }
	public void DoSomethingThatModifiesBar()
	{
		Bar = "Baz";
		OnPropertyChanged("Bar");
	}
	// snip code for implementing INotifyPropertyChanged
}

But that’s not a very common thing, and the syntactic sugar here has saved me very little. In fact, it does make the code a little less robust when it comes to maintenance, because now every place that calls the internal setter must explicitly add code to raise the PropertyChanged event.  If I hand code this instead of using an automatic property, I can put the PropertyChanged code inside the private setter and not have to worry that we’ll forget to do it somewhere in the code base.

So, what if you don’t plan to use the class in question in any databinding scenarios?  Or, in other words, you aren’t using INotifyPropertyChanged.  OK, fine.  But how many such properties have you ever coded that didn’t do some validation or something else in the setter.  Me, I can count the number of times I’ve written a setter that simply did "_bar = value;" on the fingers of my right hand.  Simple getters, yes, simple setters, no.  So, I can see using the "public get, private set" example above in some cases, such as for the Count property on a custom collection (though even there, the property is often calculated and not a simple getter).  But even for this corner case, the syntactic sugar hasn’t really bought me anything.  Slightly less code, but code snippets achieve the same result when writing the code, and the difference in the code when reading isn’t enough to make the code any clearer (in fact, I’d argue it makes it less clear).  So, I see no benefit.

Maybe there’s some weird corner case reason for this feature used within LINQ that makes it a useful thing to have added, but I’ve never seen it blogged about and I can’t fathom what such a thing would be.  No, I think this feature was added simply because many people have asked for such a feature.  Most, through ignorance and laziness, not wanting to type as much.  Those are the people who are excited about this new feature, and I they are the ones who scare me.  Good design, as I tried to illustrate above, would dictate this feature would hardly ever be used, so if you’re excited about the feature it means you’re probably not coding with good design.

That said, there’s another class of people who wanted a feature like this, and they weren’t so ignorant.  They’ve used facilities in other languages that provide syntactic sugar for defining properties that don’t make it difficult to properly design them.  Here’s a possible variation in C# that would have been useful:

property string Bar;

This would produce a property named Bar with trivial get and set implementations.  Slightly less code, but so far this doesn’t illustrate the difference in the concept yet, and is doing something that, again, good design would dictate you should hardly ever actually do.  So, let’s show how we’d make this work as in my INotifyPropertyChanged example above:

property string Bar
{
	get;
	set
	{
		@Bar = value;
		OnPropertyChanged("Bar");
	}
}

Here’s where we get some power!  I can leave the parts that are trivial out (heck, I think the above should work with out the "get;" line in exactly the same way).  The non-trivial parts can now be explicitly added.  We need a way to access the "hidden" variable generated for us here, and I chose to use the "@" sign that’s already available for specifying variable names that are keywords.  This may prove to cause problems in language implementation, and if it does, just change the "@" to "$" or use some other mechanism, I don’t care.  The point is, for property generators to be useful in the real world, you need two features missing from C# 3.0’s implementation.  You need to be able to access the "hidden" field that was generated by the compiler (possibly even from places other than getter/setter code!), and you need to be able to override individual parts (get/set) of the property to make them non-trivial implementations.  With out these features, I won’t ever use automatic properties, and I’d question any code that did.

Update:  Jomo Fisher has an article, "The Least You Need to Know about C# 3.0", where he talks about about this new feature, calling it "one of my favorite new features."  My first reaction was to roll my eyes.  Then I finished reading the sentence, and you know, he’s actually come up with a use for this feature.  It makes it "easier" to implement immutable types.  Doesn’t change my mind, because even this use case comes down to simply saving you a little typing, and I think code snippets are a better choice for doing that.  But it’s still worthy of acknowledging.

Read Full Post »