Crockford on Javascript

The web would be a better place if everyone watched “Douglas Crockford on Javascript”, a highly entertaining and informative series of lectures on the state of Javascript and the web.  With wit and refreshing candor he catalogs what is right and wrong with Javascript and provides the historical context to help viewers understand (where possible) how we got here.  You’ll almost certainly want to buy his book “Javascript: The Good Parts.”  The title alone is a nice taste of Crockford’s plain-spoken style. :-)

I’ve left the Silverlight team

I recently left the Silverlight team.  Silverlight is a great team to work for and I have tremendous confidence in the continued success of the product.  However at this point in my career platform development doesn’t appeal to me very much. I’d rather be much higher up in the stack working on user-facing technology.  To that end I’ve joined a research team that’s developing semantic web technology for Bing (among other things).

Unfortunately this will mean that I won’t be able to blog as much about what I’m doing because most of my work will be under NDA.  I can say that it is very exciting though!  If there’s one thing Microsoft does better than anyone it’s funding and productizing research (although there’s still room for improvement).

Working for the Silverlight team has been a real thrill.  It was great to be able to fight for and contribute features to the platform that I cared about. I’m proud to have been a part of Silverlight 4 and I can’t wait to use it on my new team.

A Modest Proposal: Pretty XSL

I’ve got a question for the authors of the popular MVC frameworks: What’s with all the custom view languages?  ASP.NET MVC uses ASPX files for their views.  Rails uses Ruby of course.  MonoRail has its own NVelocityViewEngine which has a python-like syntax.  Of course these frameworks allow you swap out these view engines.  However in my experience developers tend to default to using the one that ships with the framework.

Why not use XSL? 

The technical benefits of using XSL are compelling:

1. Use Less Bandwidth

Every major browser is capable of XSL transformations on the client.  After the XSL and CSS files have been cached by the browser an application server becomes responsible only for sending data and managing any application state.  This translates to massive bandwidth savings.

2. Enforce Model/View Separation

When it comes to view languages smarter is not better.  The more powerful a view language, the easier it is to inadvertently blend concerns.  XSL is a dumb language that is pure by design.  It’s like a technical straightjacket, sending a clear message to current and future developers about exactly what type of tasks are allowed to be performed.

3. W3C Standard

‘Nuff said.

4. Great tooling.

Some .NET developers may be unaware that it’s possible to step through XSL transformations in Visual Studio.  The experience is roughly on par with stepping through C# code in an ASPX.

Syntax Matters

Given all these benefits why do so many developers choose a different view language?  Here’s my theory: XSLT is ugly.  Anyone who has used XSL knows that its signal-to-noise ratio is abysmal.  Therefore propose a solution: The W3C should create PXSL (“Pretty Extensible Stylesheet Language”).  PXSL is a hypothetical non-XML language that compiles into XSL.  A stripped down version of Windsor’s NVelocityEngine or something similar could easily be compiled into XSL.

#foreach($person in $people)
#beforeall
       <table>
               <tr>
               <th>Name</th>
               <th>Age</th>
               </tr>
#before
                  <tr
#odd
                       Style='color:gray'>
#even
                       Style='color:white'>

#each
                       <td>$person.Name</td>
                       <td>$person.Age</td>

#after
                  </tr>

#between
                  <tr><td colspan='2'>$person.bio</td></tr>
#afterall
       </table>
#nodata
       Sorry No Person Found
#end

Some might think such an endeavor trivial or misguided.  I disagree.  There’s a relevant precedent to consider here.  Turtle (Terse RDF Triple Language) is a non-XML language for describing XML RDF graphs that has been submitted to the W3C.  Although it hasn’t yet been accepted as a standard it enjoys great tooling support and is widely used.  Although it is no more or less expressive than RDF it’s practical syntax is so compelling that it has found a foothold in the industry.

Use XML Where it Makes Sense

Whenever a new technology is introduced we hear a lot about its supposed benefits.  Some of these benefits pan out and some don’t.  One of the touted benefits of XML was that it was supposed to be human-readable.   While definitely an improvement on binary, many XML formats (ex. SOAP) are so complex that sifting through them in a text editor is very difficult in practice.  To increase productivity we are increasingly hiding XML from developers with designers, code generators, and configuration utilities. XML is a very mature data interchange language but there’s no reason to force developers to work with it directly.  A little syntax goes a long way.

Why We Still Rely on Dynamic Casts

*I recently updated this post as it was rather unclear.  By instance members I meant fields and properties, but it was pointed out that MTC was already supported on instance methods which are of course instance members.

The year is 2010.  I program in C#, a modern and (ostensibly) strongly-typed programming language with generics.  So why do I find it so difficult to write a program that doesn’t rely on dynamic casts?

Conventional wisdom is that reliance on dynamic casting is usually the sign of a poorly-designed framework.  While this is true very often the root cause of suboptimal framework design is the inability of the programming language to express certain concepts.  Its my aim to show you that with a simple programming language feature we can largely free our programs of dynamic casts.  In the process I also intend to challenge conventional notions about good interface design.

Why We Need Dynamic Casts: A Typical Example

Let’s take a look at a class that must rely on dynamic casts to do its job.

public class CollectionSynchronizer<T>
{
    public ICollection<T> SourceCollection { get; set; }     
    public ICollection<T> TargetCollection { get; set; }
    
    // Implementation omitted
}

This CollectionSynchronizer listens to changes in a source collection and synchronizes its contents with a target collection.  Over the classes lifetime its SourceCollection property might be set to a variety of different concrete collection classes that implement ICollection and INotifyCollectionChanged.  The CollectionSynchronizer class has to rely on a dynamic cast because it must cast its source collection from an ICollection to an INotifyCollectionChanged interface in order to detect any changes to it.

public class CollectionSynchronizer<T>
{
    private ICollection<T> sourceCollection;
    
    public ICollection<T> SourceCollection
    {
        get 
        {
            return sourceCollection;
        }
        set
        {
            sourceCollection = value;
            INotifyCollectionChanged notifyCollectionChanged = sourceCollection as INotifyCollectionChanged;
            if (notifyCollectionChanged != null)
            {
                notifyCollectionChanged += SourceCollectionChanged;
            }
        }
    }
    
    private void SourceCollectionChanged(object source, NotifyCollectionChangedEventArgs args)
    {
        // synchronize changes with target collection.
    }
    // snip...
}

The SourceCollection property cannot be strongly-typed as INotifyCollectionChanged because INCC contains no members for retrieving the objects already present in the collection (INCC doesn’t inherit from IEnumerable).  As a result of being weakly-typed this API is not discoverable to the class consumer - who might inadvertently assign a regular collection to the SourceCollection property and then wonder why the target collection was not getting updated.

“Isn’t INCC just a poorly designed interface?  Shouldn’t it derive from IEnumerable.”

No.  The architects made the right decision when they decided not to derive INCC from IEnumerable.  I’ll explain why later.  First I’ll demonstrate how we can get rid of this dynamic cast using a hypothetical language feature that is more flexible than interface inheritance and has fewer drawbacks.

Multiple Type Constraints

Ask yourself this question: Why can’t properties and fields be more than one type?  At first this question might seem heretical at best and nonsensical at worst.  Is such a thing even possible?  Well it turns out that this feature - which I’ll refer to as Multiple Type Constraints (MTC) - is not only possible to implement, but very useful. 

Let’s take a look at a revised version of our CollectionSynchronizer class that uses MTC (WARNING: the following code does NOT compile)...

public class CollectionSynchronizer // No generic type but...
{
    // ...we're using a generic type in a property definition
    public TCollection SourceCollection { get; set; } 
        where TCollection : ICollection, INotifyCollectionChanged
        
    public ICollection TargetCollection { get; set; }
    
    // Implementation omitted
}

Now objects assigned to the SourceCollection property are not restricted to being a single type but are instead constrained to be multiple types.  If C# were capable of compiling the code above we could write code like this*:

var sourceCollection = new ObservableCollection<Customer>();

// No generic type needed on the class
var synchronizer = new CollectionSynchronizer();

synchronizer.SourceCollection = sourceCollection;
synchronizer.TargetCollection = myListBox.Items;

// Adding an item to the source collection,
// and consequently the ListBox items
sourceCollection.Add(new Customer());

// Now we can change the type of SourceCollection
// to another collection that implements 
// ICollection and INotifyCollectionChanged.
sourceCollection.SourceCollection = new MyCustomCustomerCollection();

*Some folks pointed out in the comments that you could use a generic method setter with type constraints to write the same code as I’ve written above.  While this is true it would mean that I couldn’t set this property via XAML.

The point I’m trying to make is that if a programming language supports multiple inheritance it should support multiple type constraints.  C# does support MTC today, but not on properties and fields.  This causes problems.  I’ll explain further but first a small tangent…

Interface Inheritance is Harmful

I submit that the ability to inherit one interface from another has no place in a programming language.  Now I suspect you’d probably like some sort of justification for cutting a feature that pretty much every modern statically-typed, object-oriented programming language supports. 

Tough.  You’ve got it backwards.  Language features are expensive and risky propositions and therefore it’s the advocate’s responsibility to justify their inclusion - not the other way around.  So let’s ask the question…

Why Inherit?

There are two reasons to use inheritance:

1. Share implementation
2. Polymorphism

Obviously we can’t share implementation code by inheriting one interface from another because interfaces don’t contain any implementation code.  That only leaves polymorphism.

Polymorphism seems like a good reason to enable interface inheritance.  After all we can use interface inheritance to create a version of the CollectionSynchronizer class that doesn’t require a dynamic cast.

// Create new interface that inherits from two others
interface IObservableCollection: ICollection, INotifyCollectionChanged
{
}

public class CollectionSynchronizer // No generic type but...
{
    // Now we don't need generic constraints!
    public IObservableCollection SourceCollection { get; set; }         
    public ICollection TargetCollection { get; set; }
    
    // Implementation omitted
}

There’s just one problem with this approach: There aren’t any collections that implement IObservableCollection because we just invented it.  There’s no way of getting existing classes you don’t own to retroactively implement an interface. Even though the set of types in System.Collections.ObjectModel.ObservableCollection’s type hierarchy are a superset of the types in our IObservableCollection interface we can’t polymorph over both types.  Your IObservableCollection interface also won’t be compatible with semantically identical interfaces distributed by third parties.  This example demonstrates the inflexibility of interface inheritance.

The key takeaway here is that if a language supports MTC then interface inheritance is useless because MTC is a more flexible mechanism for achieving polymorphism.  In this context it makes sense to do away with interface inheritance because this feature encourages developers to build bigger, more coupled interfaces.

The Case For Small Interfaces

The larger an interface the more likely it is to be broken.  A broken interface is a big problem because interfaces don’t version.  It’s impossible to add, remove, or otherwise change members of an interface without breaking existing code.

One strategy for avoiding the embarrassment and pain of deprecation is to design many, small interfaces.  If we design interfaces that do one thing and do it well as well as avoid creating large interfaces indirectly via inheritance we  minimize the damage caused by deprecation.

The strategy of designing many small interfaces is only viable with MTC.  The fact that MTC is missing from properties and fields is a blind spot.  Nowadays systems are increasingly being built with declarative languages like XAML which are oriented around property getters and setters.

An Ideal Candidate for Language Inclusion

Property type constraints are an evolutionary concept, not a revolutionary one.  Its already possible to build  methods that specify multiple type constraints (via generics constraints).  MTC could be added to properties and fields by reusing the existing generic constraint syntax used for methods.

Tools/Designers would also benefit from multiple-type constraints on properties.  For example if a method was constrained to be both INotifyCollectionChanged and ICollection then the intellisense listing could include types that implement both.

Under the hood things get a little more complicated.  Just like generics, MTC is an ideal candidate for inclusion in IL.  Any approach that reduces MTC types to  object types or uses some other form of erasure would share the same drawbacks as generic type erasure.  I don’t pretend making the necessary changes to the platform will be easy, but I think it is worth the effort.*

*Update: Someone pointed out to me that this may actually be supported already because properties are just get/set method pairs under the hood.  Haven’t tried to write the IL myself.  Anyone know for sure?

The Way Forward

Multiple inheritance creates a combinatorial explosion of potential new types (ex. IObservableCollection, IObservableStack, IObservableEnumerableQueue, etc). MTC is an important tool for managing this complexity.   Programming languages that provide multiple inheritance without also allowing for multiple type constraints are not strongly-typed in practice.  Not allowing for constraints on properties and fields is an oversight that should be rectified.

Check me out on Channel 9 Talking about Rx and the Silverlight Toolkit

Have a look.

The Joy of Rx: Rx Released!

Rx has been released.  Enjoy.

Silverlight Toolkit Drag Drop (Part 2): Customizing Drag and Drop Behavior

In part 1 you were introduced to the new Silverlight DragDropTarget controls.  In addition to being powerful these controls are very flexible, allowing developers to customize almost every single aspect of their behavior.  In order to understand how to customize these controls you must first understand how they communicate.  The good news is that DDT’s communicate via a WPF-compatible implementation of the drag/drop events!

A WPF-Compatible (mostly) Implementation of Drag and Drop

The Silverlight Toolkit Drag and Drop Framework is a compatible subset of WPF’s drag and drop methods and events – with a few small exceptions.  The diagram below demonstrates how DDTs are layered on top of this WPF-compat framework.  DDTs use these events and methods to communicate with each other.

 

The fact that the Silverlight Toolkit contains a full implementation of WPF’s drag and drop stack gives the developer tremendous flexibility.  They can…

• Use DDTs.
• Communicate with and customize DDTs by handling the drag and drop events.
• Choose not to use DDTs and use the WPF-compat API’s to initiate and manage their own drag operations.
• Add native drag and drop support to their custom controls by implementing the IAcceptDrop interface.
• Create new DDTs for existing controls by creating a class that inherits from DragDropTarget.

Differences between Silverlight Toolkit and WPF Drag and Drop API’s

Different Namespaces

The most obvious difference between the Silverlight implementation of drag and drop and that of WPF is that the Silverlight drag and drop objects are located in the Microsoft.Windows namespace rather than in the System.Windows namespace.  When writing drag and drop code it’s good practice to insert the following code in your source file:

#if SILVERLIGHT
using Microsoft.Windows;
using SW = Microsoft.Windows;
#else
using SW = System.Windows;
#endif

Using an alias for the namespace with the drag/drop objects ensures that you can write code that can be easily ported to WPF or a future version of Silverlight with core-level drag/drop support.  All of the code samples in this series of blog posts assume that you’ve defined the alias “SW” as Microsoft.Windows in Silverlight and System.Windows in WPF.

Starting a Drag Operation

Keep in mind that if you intend to use a DDT you don’t need to know how to do this because DDT’s automatically initiate drag operations when an item is dragged.  However if you want to initiate a drag operation yourself you’ll need to know about some subtle (but necessary) differences between the Silverlight’s and WPF’s DoDragDrop methods. 

In WPF the DoDragDrop method blocks until the drag operation completes.  In Silverlight there are no blocking UI methods so it is necessary to listen for a DragDropCompleted event if you want to perform an operation when a drag completes. 

It is still possible to write cross-platform code if you use the following pattern:

// Define an action to be executed when the drag completes.
Action<SW.DragDropEffects> dragDropCompleted =
    effects => 
    {
        Console.WriteLine(string.Format(“Drag finished: {0}”, effects)));
    };
    
#if SILVERLIGHT

// Create a handler for the DragDropCompleted event which invokes the action.
EventHandler<DragDropCompletedEventArgs> dragDropCompletedHandler = null;
dragDropCompletedHandler =
    (sender, args) => 
    {
        // Detach the handler so that this action is only executed once.
        SW.DragDrop.DragDropCompleted -= dragDropCompletedHandler;
        dragDropCompleted(args.Effects);
    };

// Attach the handler to the DragDropCompleted event.
SW.DragDrop.DragDropCompleted += dragDropCompletedHandler;

// Begin the drag operation.
SW.DragDrop.DoDragDrop(
    sourceControl, 
    data, 
    SW.DragDropEffects.All, 
    SW.DragDropKeyStates.LeftMouseButton);    

#else

// If WPF then just begin the drag operation.
SW.DragDropEffects effects = 
    SW.DragDrop.DoDragDrop(
        sourceControl, 
        data, 
        SW.DragDropEffects.All);
        
// Code blocks until drag is finished...
dragDropCompleted(effects);

#endif

Note that in addition to being asynchronous the Silverlight version of DoDragDrop accepts an additional parameter: the initial DragDropKeyStates.  In the example below this is SW.DragDropKeyStates.LeftMouseButton.

SW.DragDrop.DoDragDrop(
    sourceControl, 
    data, 
    SW.DragDropEffects.All, 
    SW.DragDropKeyStates.LeftMouseButton);

In Silverlight (unlike WPF) it is not possible to sample the mouse state.  Therefore the developer must track the state of the mouse keys and pass it to DoDragDrop.  This is straightforward if, as is commonly the case, the drag operation begins with a mouse click. 

button.MouseLeftButtonDown += 
    (sender, args) =>
    {
        SW.DragDrop.DoDragDrop(
            button, 
            "Some text to transfer", 
            SW.DragDropEffects.All,
            SW.DragDropKeyStates.LeftMouseButton);
    };

Although the DragDropKeyStates enumeration is a flags enum which includes members that track keyboard states there is no need to include these.  The DoDragDrop method will sample the keyboard and update the value when invoked.

Listening to Drag Source and Drag Target Events

In WPF there are two ways to attach a handler to an event.  The first is to attach a handler to the event on the UIElement and the second is to attach a handler to the attached event object:

// Works in WPF.
myButton.DragOver += 
    new SW.DragEventHandler((o, a) => Console.Write(“button dragged over.”));

// Works in WPF and Silverlight Toolkit Drag Drop Framework.
myButton.AttachEvent(
    SW.DragDrop.DragOverEvent, 
    new SW.DragEventHandler((o, a) => Console.Write(“button dragged over.”),
    false);

Silverlight Toolkit’s Drag and Drop Framework supports the latter approach for all drag target and source events.  By using AttachEvent and RemoveEvent you can write code that will work on WPF and Silverlight.  For more information on attached events see the Attached Events Overview on MSDN.

Note: DDTs implement the familiar WPF events so you don’t need to use the more verbose attached event approach when you’re working with them.

// DragDropTarget's have the WPF events.
myListBoxDragDropTarget.DragOver += 
    new SW.DragEventHandler(
        (o, a) => Console.Write(“DDTs make everything easier!”));

Indicating that an Element Can Accept a Drop Operation

In WPF all UIElements have an AllowDrop property which determines whether they will receive drag/drop events.  As it isn’t possible to add properties to existing types the Silverlight Tookit implementation of drag and drop uses an AllowDrop attached property on the static DragDrop object:

WPF

<Rectangle AllowDrop="True" />

Silverlight

<Rectangle 
    xmlns:msWindows="clr-namespace:Microsoft.Windows;assembly=System.Windows.Controls.Toolkit" 
    mswindows:DragDrop.AllowDrop="True" />

Customizing DragDropTarget Behavior

DDT’s do their best to determine the allowed effects of a drag operation by examining the bound collection and the items inside of them.  For example if a DDT’s control is bound to a ReadOnlyCollection or an array then the allowed effects of a drag will not include DragDropEffects.Move and the allowed effects of a drop will be DragDropEffects.None.  By default a DDT never sets the allowed effects of a drag to DragDropEffects.Copy because there is no generic way of cloning an item in Silverlight (ICloneable does not exist).  But what if we wanted the effect of a drop to be a Copy operation?

Let’s say we have two DDT’s, one containing a ListBox and the other containing a DataGrid.

<StackPanel Orientation="Horizontal">
    <controlsToolkit:ListBoxDragDropTarget x:Name="listBoxDragDropTarget"  HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch">
        <ListBox x:Name="listBox" VerticalAlignment="Stretch" SelectionMode="Extended"  Height="300" >
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <Image Source="{Binding Image}" />
                        <TextBlock Text="{Binding Name}" VerticalAlignment="Center" Margin="4,0,0,0" />
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
            <ListBox.ItemsPanel>
                <ItemsPanelTemplate>
                    <StackPanel Orientation="Vertical" />
                </ItemsPanelTemplate>
            </ListBox.ItemsPanel>
        </ListBox>
    </controlsToolkit:ListBoxDragDropTarget>
    <dataToolkit:DataGridDragDropTarget x:Name="dataGridDragDropTarget" msWindows:DragDrop.AllowDrop="true"  HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch">
        <data:DataGrid x:Name="dataGrid" AutoGenerateColumns="False"  Height="300" >
            <data:DataGrid.Columns>
                <data:DataGridTextColumn Binding="{Binding Name}" Header="Name" />
                <data:DataGridTextColumn Binding="{Binding Reputation}" Header="Reputation"  />
                <data:DataGridTextColumn Binding="{Binding GamerScore}" Header="GamerScore" />
            </data:DataGrid.Columns>
        </data:DataGrid>
    </dataToolkit:DataGridDragDropTarget>
</StackPanel>

Each control is bound to an collection of Gamer instances.

class Gamer {
    public string Name {get; set}
    public double Reputation {get; set}
    public int GamerScore {get;set;}
    
    // Our custom copy method.
    public Gamer Clone()
    {
        return 
            new Gamer 
            {
                Name = this.Name,
                Reputation = this.Reputation,
                this.GamerScore = this.GamerScore
            };
    }
}

// snip...

// No need to use an ObservableCollection.  We don't
// want items removed from the ListBox.
listBox.ItemsSource = 
    new []
    {
        new Gamer 
        { 
           Name = "Mark Rideout",
           Reputation = 82.234,
           GamerScore = 23432
        },
        // etc.
   };

// Using an observable collection ensures that changes
// to the items source collection will be reflected 
// in the grid immediately.
dataGrid.ItemsSource =
    new ObservableCollection<Person>(); 

When the user drags Gamers from the ListBox to the DataGrid we’d like to add a copy of the Gamer object to the DataGrid rather than add a reference to the object in the ListBox to the DataGrid’s bound collection (the default action).  In order to ensure that when an item is dragged from a ListBox the allowed effect is DragDropEffects.Copy rather than DragDropEffects.Link we set the ListBoxDragDropTarget’s AllowedSourceEffects property.

listBoxDragDropTarget.AllowedSourceEffects = SW.DragDropEffects.Copy;

Since the DataGridDragDropTarget doesn’t know how to handle a Copy operation we need to handle its Drop event.

using System.Collections.ObjectModel;

// snip...
dataGridDragDropTarget.Drop += 
    (sender, args) =>
    {
        // Only handle this event if it's a copy.  If the event is not handled
        // the DDTs base implementation of Drop will execute.
        if ((args.AllowedEffects & SW.DragDropEffects.Copy) == SW.DragDropEffects.Copy)
        {
            IList<Person> dataSource = dataGrid.ItemsSource as IList<Person>;
            
            // Retrieve the dropped data in the first available format.
            object data = args.Data.GetData(args.Data.GetFormats()[0]);
            
            // The data is the ItemDragEventArgs that was created by the DDT when
            // the drag started.  It contains a SelectionCollection.
            // SelectionCollection's are used by DDTs because they can transfer 
            // multiple objects.  The fact that they store the indexes of the 
            // objects within the source collection also makes reordering items
            // within a source possible.
            ItemDragEventArgs dragEventArgs = data as ItemDragEventArgs;
            SelectionCollection selectionCollection = dragEventArgs.Data as SelectionCollection;
            if (selectionCollection != null)
            {
                IEnumerable<Gamer> gamers = selectionCollection.Select(selection => selection.Item).OfType<Gamer>();
                if (gamers.Any())
                {
                    foreach(Gamer gamer in gamers)
                    {
                        // Invoke our custom Clone method to make a copy.
                        dataSource.Add(gamer.Clone());
                    }
                    args.Effects = SW.DragDropEffects.Copy;
                    args.Handled = true;                
                }
            }
        }
    };

Now when we drag items from our ListBox to our DataGrid we will get copies of the Gamer objects and the ListBox’s contents will be unchanged.

There are many more extensibility points in DDT’s.  I encourage you to take a close look at the events and properties.  I think you’ll be impressed by how flexible these controls are.

Powerful and Flexible

By now it should be clear that the Silverlight Toolkit Drag and Drop Framework is more than a few DDTs that add drag and drop behavior to a certain Silverlight controls.  It is also a rich set of WPF-compatible events and methods that can be used with any Silverlight control - including your own!

Next time: Adding Drag and Drop support to your custom controls!