Omer van Kloeten's .NET Zen : Orcas

Expression trees' ConstantExpression values

Omer van Kloeten — Thu, 04 Oct 2007 00:25:00 GMT

After reading Jafar Husain's posts (1, 2 and bonus by Doron Yaacoby), I started thinking about being able to strong type names using the Expression classes.

One of the things I came up with is creating a tracing framework where Expression is passed, instead of strings or other untyped methods.

[Conditional("DEBUG")]
public static void TraceStart<T, R>(
    this T me, Expression<Func<T, R>> where) {
    // ...
}

[Conditional("DEBUG")]
public static void TraceEnd<T, R>(
    this T me, Expression<Func<T, R>> where, R returnValue) {
    // ...
}

class Foo
{
    public bool Bar(int param)
    {
        this.TraceStart(o => o.Bar(param));

        this.TraceEnd(o => o.Bar(param), false);

        return false;
    }
}

Since the TraceStart and TraceEnd methods are decorated with a ConditionalAttribute, the Expression objects will not even be created (since the calls will not be made).

Nice idea, but the overhead during debugging might just be too much.

Here's where the interesting bit comes in: While I was fiddling with the idea, I tried to print the value of param, by reaching the expression tree's ConstantExpression for it. However, the type in the expression's Value property was of a type named: Namespace.Foo+<>c__DisplayClass0.

OK, so where do I get the value from? Apparently, Namespace.Foo+<>c__DisplayClass0 has a public field named value. That's where. Oh, but wait. You can't get it - since it's a field, you can't get it using polymorphism, but even if it was a property, Namespace.Foo+<>c__DisplayClass0 doesn't inherit or implement anything.

Resorting to reflection seems like a terrible solution. I just hope that this will change until C# 3.0 RTMs.

Extension Methods and Trust

Omer van Kloeten — Sat, 14 Apr 2007 18:52:00 GMT

As much as I love the idea behind extension methods, I can't help but start to think about how it could be used for malicious purposes.

Take this scenario:

You're a disgruntled employee of Evil Inc., the makers of the well known library VeryUsefulAssemblies.NET.
I'm a developer at Good & co., using your Tree<T> class in an assembly called Evil.UsefulAssembly.
Before quitting your job, you decide to add an extension method, System.String.Format(params object[] args), that sends sensitive information back to you and then calls System.String.Format(string format, params object[] args) so no one notices.
I have now unwillingly compromised all of my clients and could never know it, unless I manually check my IL or use a sniffer.

But wait! There's more:

A fellow developer in my company, Norman I. Huntington, decides to write his own Tree<T> and replace all of the references to your Tree<T>, but he forgets to remove the reference to your assembly.
Now my application doesn't even use your assembly, but is still hijacked!

Problem? I think so.

Generic Windows Forms Controls

Omer van Kloeten — Thu, 08 Mar 2007 22:13:47 GMT

Today I discovered that the Windows Forms Designer in Visual Studio 2005 doesn't know how to handle generics. For instance, the following example:

private class MyControl<T> : System.Windows.Forms.Control
{
}

could not be dropped in a Windows Forms designer (more on that in a little bit). If you go and decide to be a smart ass (like I usually am) and cheat the designer, you could drop a Panel (or any other control and manually edit the code in the InitializeComponent method and the Form.Designer.cs file to the class you want like so:

#region Windows Form Designer generated code

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
    this.panel1 = new MyControl<int>();

    // ...
}

#endregion

private MyControl<int> panel1;

This would throw the designer into a hissy fit:

The solution? Here are my suggestions for the VS Team:

Dropping a generic control - My suggestion is that when a generic control is dropped, each type parameter will have a default value (can be decided on by using attributes, much like the DefaultValueAttribute) and will be editable in the property grid with a specialized designer.
Having a generic control on a Form - It's a bug and should be fixed. I know for certain that I am not the first person to come across this problem and that there is a workaround, but this is just annoying.

Linq Extensions Beta 1 Now On CodePlex

Omer van Kloeten — Sat, 14 Oct 2006 12:03:35 GMT

My new Linq Extensions project for the Linq May CTP is now up on CodePlex and I've released beta 1 (numbered 0.1).

It took me a while to understand how to work with it and the connection to the Team Foundation Server wasn't as fast as I had hoped, but now it's ready for use.

Currently implemented are the following:

Hierarchy
Reverse Hierarchy
Binary Tree
- Infix Traversal
- Prefix Traversal
- Postfix Traversal
Graphs
- Breadth-First Traversal
- Depth-First Traversal
In

A FAQ and examples will be written soon, but it's pretty straight forward. You can open bugs and feature requests using the Issue Tracker. The release is downloadable here.

PS: Since the System.Query assembly is not signed, which I'm guessing is because this is only a CTP, so the DotNetZen.Query assembly is not signed.

Should Humans Be Called Ape2?

Omer van Kloeten — Wed, 11 Oct 2006 03:17:00 GMT

Ever since Kathy Kam announced on her weblog that a new type named TimeZone2 will be introduced into the Orcas release of .NET, the community has been in an uproar, claiming the new name is horrible and that we're going back to the days of Win32 and COM with types like TimeZone3 and DateTimeEx not far down the line.

TimeZone2 comes to replace TimeZone in order to support Vista's Dynamic Time Zone APIs and offer some other new functionality.
According to Krzysztof, the team had several options:

Deprecate the current TimeZone using ObsoleteAttribute and use the same type for the new functionality, but this, according to Krzysztof, will simply not happen.
Use a new namespace, but this will cause confusion, since the type name would have to be fully qualified.
Find a better name, yet no one has been able to come up with one that would satisfy the team.
Call it TimeZone2.

Unfortunately, they decided on the last option, backed by an invocation of a Design Guideline (And none other than one of the very few guidelines I wholeheartedly disagree with).

I, personally, am with the Break Camp: Simply take the old functionality and deprecate it or just remove it altogether. The Orcas framework is to be released at version 3.* (a change of the major version since the last release), which means to users that breaking changes are acceptable and even expected. I have never heard known of a single serious software developer that has taken for granted that their applications will simply work when moving from .NET 1.0 to .NET 2.0 and I don't think I'll ever hear of one blindly moving to .NET 3.0.
Want to make it easier on your customers? Create an automatic tool (maybe as part of Visual Studio Orcas) that translates current behaviour to 3.0 behaviour.

Invoking the Red-Bits-In-Place-Service-Pack excuse is moot here, since it was the wrong call to make in the first place. Backwards compatability is not the Holy Grail.

This is the very first step on the road to making the .NET Framework an unusable patch-work. Just imagine a developer new to .NET which starts with version 3.0 and sees TimeZone and TimeZone2.

The CLR Team's posts about this in chronological order:

Orcas September CTP available... Hello "System.TimeZone2"!
System.TimeZone2 Starter Guide [Kathy Kam]
Designing System.TimeZone2 - Part 1 (API naming and new class or not)
Designing System.TimeZone2 - Part 2 (Dynamic Time Zone support)
System.TimeZone2 Naming ... and related design guidelines
Naming Guideline Discussion
When there is no good name...

[Update: The team went back to the whiteboard and renamed it TimeZoneInfo.]

Lambda Expressions, Anonymous Methods and Methods

Omer van Kloeten — Sun, 09 Jul 2006 21:47:00 GMT

I really think Krzysztof and friends should post some guidelines in the spirit of The Framework Design Guidelines (read: The Book You Must Read) for lambda expressions, anonymous methods and methods, so there won't be any mixup as to what should be used. I'd hate to see people start writing long anonymous method in the middle of their code - they really disturb the flow.

My suggestion:

Do use a lambda expression if it consists of only one expression. This is what they're there for.
Avoid using a lambda expression if the types of parameters and return value are not obvious.
Do use an anonymous method if it consists of between 1 and 4 lines of code.
Consider a method instead if an anonymous method if it looks unreadable in the context of the code around it.
Do Not use an anonymous method if the code contained in it needs to be re-used.

And also:

Do match the names of parameters from the delegate's declaration when declaring them in a lambda expression or an anonymous method.

Again, this is my opinion and the principles I try to follow in my code. I'd love to hear your ideas too.

I'd also love to see a refactoring feature in Orcas that lets you refactor between lambda expressions, anonymous methods and methods.

Hierarchical Linq Queries

Omer van Kloeten — Sun, 09 Jul 2006 14:24:00 GMT

After reading Bill Wagner's excellent introduction to Linq, I really liked what I saw and decided that I wanted to create an extension method as an exercise. I sat and thought what I would have wanted from Linq and decided I wanted to write a method that lets you select hierarchical data.

Here's a mockup of how a query would look like:

from   node in tree.ByHierarchy<HierarchicalData>(startWith, connectBy)
select node;

Each 'node' in the query will be an object holding the original item, its level of depth in the hierarchy and its parent (for convenience's sake):

public class Node<T>
{
    public int Level;
    public Node<T> Parent;
    public T Item;
}

This node will be used to determine what the item is and where it's located.
Let's take an example:

Tree t7 = new Tree { Value = 7 };
Tree t6 = new Tree { Value = 6 };
Tree t5 = new Tree { Value = 5, Left = t6, Right = t7 };
Tree t4 = new Tree { Value = 4 };
Tree t3 = new Tree { Value = 3 };
Tree t2 = new Tree { Value = 2, Left = t3, Right = t4 };
Tree t1 = new Tree { Value = 1, Left = t2, Right = t5 };
 
Tree[] treeNodes = new Tree[] { t1, t2, t3, t4, t5, t6, t7 };
 
var nodes = from   node in treeNodes.ByHierarchy<Tree>(
                               t => t == t1,
                               (parent, child) => (parent.Left == child) ||
                                                  (parent.Right == child))
            select node;
 
foreach (LinqExtensions.Node<Tree> n in nodes)
{
    for (int i = 0; i < n.Level; i++) Console.Write(' ');
 
    Console.WriteLine("Node {0}, child of {1}.",
                      n.Item.Value,
                      (n.Parent != null ? n.Parent.Item.Value.ToString() : "no one"));
}

This example will walk on the tree (which so happens to be a three-tiered complete binary tree) and print it in the order of hierarchy:

Node 1, child of no one.
 Node 2, child of 1.
  Node 3, child of 2.
  Node 4, child of 2.
 Node 5, child of 1.
  Node 6, child of 5.
  Node 7, child of 5.

And here's the code that does this:

using System;
using System.Collections.Generic;
using System.Query;

namespace DotNetZen.Linq
{
    public static partial class LinqExtensions
    {
        public class Node<T>
        {
            internal Node()
            {
            }
 
            public int Level;
            public Node<T> Parent;
            public T Item;
        }
 
        public static IEnumerable<Node<T>> ByHierarchy<T>(
            this IEnumerable<T> source,
            Func<T, bool> startWith, 
            Func<T, T, bool> connectBy)
        {
            return source.ByHierarchy<T>(startWith, connectBy, null);
        }

        
        private static IEnumerable<Node<T>> ByHierarchy<T>(
            this IEnumerable<T> source,
            Func<T, bool> startWith,
            Func<T, T, bool> connectBy,
            Node<T> parent)
        {
            int level = (parent == null ? 0 : parent.Level + 1);
 
            if (source == null)
                throw new ArgumentNullException("source");
 
            if (startWith == null)
                throw new ArgumentNullException("startWith");
 
            if (connectBy == null)
                throw new ArgumentNullException("connectBy");
 
            foreach (T value in from   item in source
                                where  startWith(item)
                                select item)
            {
                Node<T> newNode = new Node<T> { Level = level, Parent = parent, Item = value };
 
                yield return newNode;
 
                foreach (Node<T> subNode in source.ByHierarchy<T>(possibleSub => connectBy(value, possibleSub),
                                                                  connectBy, newNode))
                {
                    yield return subNode;
                }
            }
        }
    }
}

Three Lines About Lambda Expressions

Omer van Kloeten — Fri, 07 Jul 2006 14:09:00 GMT

myObject.ITakeACharReturningDelegate(delegate(int i, string s) { return s[i]; });
myObject.ITakeACharReturningDelegate((i, s) => s[i]);

Both are the same. That's it, in a nutshell...
[Update: The HTML was malformed in the post. Sorry about that.]