Tuesday 12 June 2012

Function.create

Some weeks ago I mentioned this page. From there you can see what is being proposed for ES.next, the JavaScript of the future.

Looking at all the interesting (and some not so interesting) additions being debated or already approved, I tried to think of things that I'd like added.

  • One of them would be a huge change, and in fact could be of quite little use, extending the prototype mechanism to provide "multiple prototype inheritance". Well, with all the versatility of JavaScript we can have a sort of Multiple Inheritance just by extending (augmenting) the initial prototype (the main parent) with the items in the prototype of the second class
    
    Employee.prototype = new Person();
    $.extend(Employee.prototype, BusinessAsset.prototype);
    
    but that has some drawbacks, as explained here mainly the instanceof operator won't work for the additional base. As I think JavaScript is much more given to duck typing that to this kind of type checks, I guess we can live without it, but anyway, I think it would be nice that the [[prototype]] and prototype properties pointed to an Array instead of an object (I think to remember that's how it works in Python where __bases__ is an array)
  • The other one came to my mind influenced by the importance that Object.create seems to have gained with JavaScript 5. Indeed, I intend to write something (if I really grasp it...) about the advantages of Object.create vs constructors (you know, the common discussion now about whether JavaScript's "new" Keyword should be Considered Harmful.
    My idea is: wouldn't it be useful to have a Function.create function, that would allow us to choose the [[prototype]] for our function (instead of being forced to have the Function.prototype one)?

    Something along these lines:
    var extraFunctionality = {
    bind: function(){...},
    memoize: function(){...}
    }
    var myFunc = Function.create(extraFunctionality, function(){
    ...
    });
    

    So, you could be wondering, what does this buy us? Well, it's commonly accepted that modifying the prototype of base objects is bad practice, so adding functions to Function.prototype (prototype.js has got us used to it) should probably be avoided.
    A good solution would be grouping this functions in one object and then use that hypothetical Function.create function. An advantage of this is that we could add functions to only certain functions, and not all (for example, we could use this technique to add "memoize" only to some functions).
    This would also allow us to have functions which [[prototype]] would be null, losing this way the call and apply methods.
    If objects are allowed to have a null [[prototype]], why shouldn't functions be also allowed? (well, maybe because a function could be defined as an object which [[prototype]] points to Function.prototype).
    Well, the idea is confusing, bear in mind that we would then have prototype chains applied to functions... in a sense, thinking in terms of class based languages, in the end it would be like allowing inheritance between functions (methods).

    OK, all this is probably a nonsense, and all we should do is directly augment our functions themselves, something rather more conventional:

    $.extend(myFunction, {
    {
    bind: function(){...},
    memoize: function(){...}
    }
    

Tuesday 5 June 2012

C# vs Java: Return Type Covariance

Covariance and Contravariance is a complicated topic that occasionally comes up again while coding something and as a consequence has me searching back into my memories to retrieve lessons learnt about it in the past. In fact, a long while ago I started to write a long post/self help document, but never managed to finish it (so far)

The topic showed up again last week, while dealing with method hiding. I came across several comments in StackOverflow stating that the main use of method hiding in C# is to simulate return type covariance. Return type covariance allows us to "narrow" the return type of an overriding method in the derived class, that is:

public class Foo {
}
 
public class SubFoo extends Foo {
}
 
public class Bar {
    final Foo foo = new Foo();
    public Foo getFoo() {
        return foo;
    }
}
 
public class SubBar extends Bar {
    final SubFoo subFoo = new SubFoo();
 
    @Override
    public SubFoo getFoo() {
        return subFoo;
    }
}

I've taken the above correct Java code (Java supports return type covariance since version 5) from here. Unfortunately, the equivalent C# version won't compile

So well, what about the idea of working around this limitation with Method Hiding?
Well, in principle that seems OK when the method being hidden is not virtual. Let's say we have an instance of the Child class, being pointed by a parent class variable. The call will end up being dispatched to the method in the Parent class, with in this case comes as not surprise, as we know static dispatch is being applied. Nonetheless, if we used method hiding for a virtual method in the Parent class (that's the case 2 in my previous article) we again will end up calling to the Parent method (cause the slot in the Child vTable is pointing there), which many people could consider as an unwanted outcome. What is for sure is that it's confusing.

Anyway, after some fast thinking on this I came up with this naive way to circumvent this limitation

public class Location
{
  public string Name{get;set;}
}

public class City: Location
{
  public int Population{get;set;}
}

public class Animal
{
  public virtual Location GetFavoritePlace()
  {
   return new Location(){Name = "forest"};
  }
}

public class Person: Animal
{
  public override Location GetFavoritePlace()
  {
   return this.GetFavoriteCity();
  }
 
  public City GetFavoriteCity()
  {
   return new City(){Name = "Berlin", Population = 4000000};
  }
}

Well, in fact it does not look that bad. We're keeping the polymorphism. Someone calling into GetFavoritePlace with an Animal variable pointing to a Person instance will still get a City object as return, which is something I consider fundamental to regard this as a valid option. On the other side, if someone is really expecting a City it's because he knows that the object on which he is doing the invocation is a Person, so he can do a downcast and call to GetFavoriteCity

After writing that and feeling partially satisfied, I decided to search a bit what others had to say on this matter, and I found this brilliant solution, that I've used below to reimplement the previous sample

public class Animal
{
  public Location GetFavoritePlace()
  {
   return this.GetFavoritePlaceImplementation();
  }
  
  protected virtual Location GetFavoritePlaceImplementation()
  {
   return new Location(){Name = "forest"};
  }
}

public class Person: Animal
{
  public new City GetFavoritePlace()
  {
   return (City)this.GetFavoritePlace();
  }
 
  protected override Location GetFavoritePlace()
  {
   return new City(){Name = "Berlin", Population = 4000000};
  }
}

An interesting question stems up from all this, why doesn't C# support return type covariance for normal methods (it does support it for Delegates since C# 2.0 and for Generic Interfaces since C# 4.0). I can't think of any real reason for this (remember that Java supports it), and after much googling all I've found is that it's not supported at the CLR level, and some comments by Eric Lippert that confirm the problem but don't really explain the reason (also Jon Skeet does some mention to methods returning void, but I don't fully grasp the implications)

Friday 1 June 2012

Simulate MultiMethods with the Visitor Pattern

There are some Design Patterns that become part of your everyday life, there are others that you rarely use and keep fading somewhere in your mind. One friend of mine mentioned the other day having being questioned about the Visitor Pattern when doing a job interview. That made me think a bit about its use and implementation, and then I recalled that apart from its typical use when building compilers, part of the reason for this pattern is simulating MultiMethods (Dynamic Dispatch). It pretty much called my attention that the entry in Wikipedia does mention this, but does not include a sample, which prompted me to write my own.

Sure there are millions of much better samples one google search away, but hey, I feel like sharing it anyway

public abstract class Person //item to be visited
{
 public string Name{get;set;}
 
 public abstract bool TryToEnter(Party party); //Accept
}

public class Employer: Person
{
 public override bool TryToEnter(Party party)
 {
  return party.Admit(this);
 }
}

public class Employee: Person
{
 public override bool TryToEnter(Party party)
 {
  return party.Admit(this);
 }
}

//visitor
public class Party 
{
 //Visit method
 public bool Admit(Employer e) 
 {
  return true;
 }
 
 public bool Admit(Employee e)
 {
  return false;
 }
}

public class App
{
 public static void Main()
 {
  var party = new Party();
  var persons = new List<Person>()
  {
   new Employer(){Name="Xuan"},
   new Employee(){Name="Xose"}
  };
  
  foreach(Person p in persons)
  {
   if (p.TryToEnter(party))
    Console.WriteLine(p.Name + " entered the party");
   else
    Console.WriteLine(p.Name + " DID NOT enter the party");
  }
 }
}

I have to say that this technique for simulating MultipleDispatch seems terribly artificial to me. The Accept method (TryToEnter in this case) that you have to add to the element on which you want to base your dispatch, appears like an ugly hack, cause it has nothing to do with the semantics of the (Person) class. Indeed, we've had to alter our thinking, with multimethod support we would just call to Party.Admit, and not the other way around as we're doing now with Person.TryToEnter.
Anyway, you can grab the code here

C# vs Java: Method Overriding and Hiding

I assume almost everyone reading the technical entries in this blog knows what method overriding is. Nonetheless, Method Hiding is not so widely known. I'll be focusing on C# here, as hiding instance methods in Java does not seem to exist (more on this at the end of the article).

We say a method in a derived class hides a method in the base class, when both methods have the same signature and the derived one is not overriding the base (virtual) one. Unless we want to get a compiler warning, we should use the "new" keyword in the method declaration to indicate that we intend to hide the Parent method. We have several different situations here:

  • We have a non virtual method in the Base class. If we want a different behavior for that method in the Child class, we can hide it. What method will be invoked here is 100% a compile time decision, there's not vTable involved, and irrespective of the real instance held by a variable, it's the type with which that variable was declared what determines what method will be called. This is pure static dispatch.
  • We have a virtual method in the Base class. If declaring the same method in the Child class with "new" instead of "override" we're somehow breaking the polymorphism. Let's say we have an instance of the Child class. If we invoke the method via a Parent variable, the Parent method is called (the entry in the Child class vTable points to the Parent method), however, if we invoke it from a variable of the Child class, no dynamic dispatch-vTable is used here, the compiler just emits a call to the method in the Child class
  • public class Animal{
      
     public virtual void Walk(){
      Console.WriteLine("Animal::walk");
     }
    }
    
    public class Person: Animal{
     
     public new void Walk(){
      Console.WriteLine("Person::walk");
     }
    }
    
      Animal a1 = new Person();
      //prints Animal::Walk, so the the walk slot in Person's vTable points to the parent's method
      a1.Walk();
      
      Person p1 = new Person();
      //no vTable involved here, it just prints Person::Walk
      p1.Walk();
    
  • There's one third case here, when you use the virtual new combination. In this case it's as if you were breaking the Polymorphism chain to that point, and starting a new one from there

    public class Animal{
     public virtual void Run(){
      Console.WriteLine("Animal::Run");
     }
    }
    
    public class Person: Animal{
     public virtual new void Run(){
      Console.WriteLine("Person::Run");
     }
    }
    
    public class Employee: Person{
     public override void Run(){
      Console.WriteLine("Employee::Run");
     }
    }
     
      a1 = new Animal();
      a1.Run();
      a1 = new Person();
      //prints Animal::Run, so the vTable slot for Person points to the parent one
      a1.Run();
      
      p1 = new Person();
      //prints Person::Run, so it seems like there's a second slot in the vTable
      p1.Run();
      
      //polymorphism works fine using that second slot, both methods write Employee::Run
      p1 = new Employee();
      p1.Run();
      Employee e1 = new Employee();
      e1.Run();
     
     }
    }
    
    So, it seems like for the Person class we get 2 different slots in its vTable, one for Animal::Run and another one for Person::Run, and at invokation time the slot selected depends on the type of the variable holding the reference to the instance.

You can get the source here

And now, the natural question that stems from this: is all this Method Hiding thing any useful? (take into account that as stated above, Java seems to lack,or maybe I should say avoid, this feature). Well, in principle, I can't think of good reasons to resort to this, excepting the one explained here, that is, working around somehow the lack of return type covariance in C# methods (notice that Java has this feature). I plan to write a brief post about this topic in short.
Well, for the first case listed above, maybe it makes some sense. If someone missed declaring a method virtual, and you need to "override" it in your derived class, you still can sort of fix it by hiding it, but at the same time, this might be risky, cause not declaring it virtual could be a rather deliberate decision, so with hiding you're sort of violating the rules set by the base class designer.
For cases 2 and 3, I don't see why you could need to use this. That said, I'm not sure whether having this feature in C# is good or bad, it gives you more chances in case for some odd reason you need it, but it can also give place to more complex code and to unexpected behaviors

To complete this entry, I think we should review the main differences between C# and Java in this arena.

  • By default Java methods are virtual and C# methods are non virtual. Used to dynamic languages, I think I prefer the Java approach, in fact, I think I would always go for the dynamic dispatch approach.
  • There's not an equivalent to "new" in Java. If you apply the final keyword to a method in a derived class, you get a different effect from what we get in C#'s case 2. We're not breaking the polymorphism, the new method is added to the corresponding slot in the vTable, but we're preventing new derived classes from further overriding.
  • public class Animal{
     public void walk(){
      System.out.println("Animal::walk");
     }
    }
    
    public class Person extends Animal{
     public final void walk(){
      System.out.println("Person::walk");
     }
    }
    
    Animal a1 = new Person();
    //prints Person::walk, so even when declared final in the child, this method seems to be added to the slot in the //Child vTable
    a1.walk();