I’ve been busy on my Silverlight test control and it’s been more fun than I’d expected and it’s actually been a lot easier than I’d expected, too.  So what I’ve been doing is delving into some of the more internal differences to extend what I’d originally planned further.

From a layout perspective, Silverlight 3 is very similar to what I would do in WPF, but it’s much more basic.  You can do many of the same things, but with Sl, it’s pretty scaled down.  By this I mean that WPF is a richer framework and handles some of the details that you otherwise have to do manually in Silverlight.

One thing I’ve noticed is that Silverlight is very lean with its overloaded constructors.  I’m not complaining, it’s an observation.  I’ll give a real example.

In WPF, I could make a rotate transformation like this:

  child.RenderTransform = new RotateTransform((angle * 180 / Math.PI));

The problem  with doing that in Silverlight is that RotateTransform only has the default constructor.  Fortunately, C# 3 included Object Initializers, so the alternate syntax I have to use is completely painless:

  child.RenderTransform = new RotateTransform()
       { Angle = (angle * 180 / Math.PI) };

How awesome is that?

So you still have the benefit of a lighter footprint without the overloaded constructors (which are just get/set anyway in this case), but still painlessly instantiate and initialize the object.

There needs to be a word of caution to newer programmers.  Don’t assume that you can universally bypass all overloaded constructers using Object Initialization as I’ve done above.  While a significant number of such constructors are nothing more than get/set convenience mechanisms, this is not the case every time.

Object Initialization is easier to read than a parameterized, overloaded constructor.  Just don’t forget that constructors can (and often) do more than just initialize properties.

Know your code!

Popularity: 7%