The Nemerle Project Blog

23 Jul 2006: Late binding

Kamil Skalski (nazgul@omega.pl), Michal Moskal (malekith@pld-linux.org) — Sun, 23 Jul 2006 13:55:00 GMT

Recently one of Nemerle users played a little bit with our macro system and implemented a feature allowing dynamic invocation of methods or accessing properties in a quite clean way (as you probably know, Nemerle is entirely statically typed and forces your code to be compliant with .NET standard object-oriented access to classes). The simplest example is

def getLength (obj : object) late obj.Length System.Console.WriteLine (getLength ("Grey goo")) System.Console.WriteLine (getLength ([1,2,3])) System.Console.WriteLine (getLength (System.Windows.Forms.LinkArea ()))

Here we just want a method to fetch the Length property of given object and late keyword introduced by macro allows us to do so easily. The biggest advantage here is that we do not care about the intefaces and common supertypes of object we use this on, so we can apply this method to ANY object (which is assumed to contain the correct property). The call will be made using .NET's dynamic invocation feature.

The idea is a little bit similar to something called duck typing (though the name is a bit politically controversial in my country at the moment ;p), but in case of our macros it works in a different way. We do not introduce any dummy "types" for objects, which are not type-checked, but we allow user to specify which parts of code should be dynamic (for more detailed specification see a deciated page).

Now the question is why is it really useful? In general I'm always heading towards the perfect world and I prefer my programs to be proved being perfect and safe. Type inference is a powerful Nemerle's feature, which helps here - I do not need to specify types of variables and compiler can infer what I mean; if it can't, it usually means I made some mistake. But here comes the problem, sometimes the code we write is simply not compatible with language / platform type system and compiler complains about my code even though I know it is right. Let us consider another example:

#pragma indent using Nemerle.Late public class Pixel mutable shift = 0 public Draw () : void System.Console.Write (string (' ', shift)) System.Console.Write ("*") public Move (dx : int) : void shift += dx public class Triangle public Draw () : void System.Console.Write ("/^\\") def perform (x : object, with_move = false) late x.Draw () when (with_move) x.Move (5) x.Draw () System.Console.WriteLine () perform (Pixel (), true) perform (Triangle ())

Now as you can see my perform function is quite tricky - it does not call Move on object if I do not specify with_move parameter to be true. So its contract is something like "calls Draw, but if we want move also calls Move", which is not expressible in any simple type system (e.g. .NET). With our late binding macro we just ignore the type system and perform all calls dynamically. :)

One more thing to notice here is that usually we can avoid dynamic calls by using well designed object hierarchy and interfaces (if we are not too lazy of course ;) ). In our example we can easily make the call to Draw statically safe, by introducing the IDrawable interface.

public interface IDrawable Draw () : void public class Pixel : IDrawable mutable shift = 0 public Draw () : void System.Console.Write (string (' ', shift)) System.Console.Write ("*") public Move (dx : int) : void shift += dx public class Triangle : IDrawable public Draw () : void System.Console.Write ("/^\\") def perform (x, with_move = false) x.Draw () when (with_move) late x.Move (5) x.Draw () System.Console.WriteLine ()

Note that now type inference comes in help - the signature perform (x : IDrawable, with_move : bool) : void is automatically guessed by compiler. The only late bound operation now is a call to Move. To solve this we could do two things:

write a specialized perform_with_move function, which would take IMovable or simply Triangle, but this would yield code duplication and additional efforts
cast to more specific type before calling Move, which makes your code a little bit uglier and you must know exactly which type to cast to.

The other cases when late binding might be useful is when you use a platform's feature, which is very dynamic by nature - like using types obtained through COM.

The Nemerle Project Blog

23 Jul 2006: Late binding

16 May 2006: Nemerle 0.9.3 hits The Outside World

24 Jan 2006: Nemerle 0.9.2 in the wild

21 Dec 2005: Recent changes

Yield

List comprehensions

04 Nov 2005: Nemerle 0.9.1 is out

Availability

Language changes

Additions

The library

Bugfixes

02 Oct 2005: The Nemerle course for OOP programmers starting on Monday

14 Sep 2005: Nemerle 0.9.0 is out

C# 4.0 today!

In general

Availability

Language changes

New features

Other stuff

Bugfixes

06 Sep 2005: Aug CTP and Mono 1.1.9, completion and forums

Generics status

Completion engine

Forums and online course

08 Aug 2005: Generics branch merged into trunk

01 Jul 2005: It boots!

01 Jun 2005: Nemerle 0.3.2 released!

02 May 2005: Nemerle 0.3.1 released!

29 Apr 2005: Nemerle 0.3.0 released!

24 Apr 2005: Generics progress

06 Apr 2005: New web site

31 Mar 2005: Nemerle 0.2.10 released!

22 Mar 2005: Nemerle 0.2.9 released!

13 Mar 2005: Intersection types

06 Mar 2005: Dots, vlists and matching

17 Feb 2005: Porting tests from C# to Nemerle

Cleaning meta-data information

27 Jan 2005: Comments ;-)

26 Jan 2005: What I think about exceptions performance

16 Dec 2004: Debugging support for Nemerle and other news

18 Sep 2004: Nemerle 0.2.1 released!

12 Sep 2004: Nemerle 0.2.0 released!

07 Sep 2004: Type inference reloaded

30 Aug 2004: Exceptional syntax and the need of a better parser

28 Aug 2004: 0.2.0 and new type inference engine approaching

11 Aug 2004: Contributors, assembly attributes and Nemerle marries GAC

New people contributing to Nemerle project

Signing assemblies with assembly attributes

Nemerle + GAC

30 Jun 2004: Nemerle 0.1.4 released

The language

The library

The compiler

Other stuff