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(){...}
  }
  

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)

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();

Interesting stuff from these last months

It's been a long while since my last post of the kind "last month's interesting stuff", but I have several interesting things from the last months that I'd like to "serialize" and that I've not been able to fit into any other entry, so here it goes a new mash up.

• Good question in Stack Overflow about "Utility methods"
• Astonishing article comparing C# closures with Java pseudo closures http://csharpindepth.com/Articles/Chapter5/Closures.aspx
• Excellent write up about the usage of GPU's for General Computation
• .Net IL (bytecodes) has to instructions for calling methods call and callvirt. Contrary to what you could expect, for most of the non virtual method invocations, callvirt is used instead of call. Yes, sounds confusing, but there's a good explanation here. Slightly related to that, you can read here some thoughts about the overuse of virtual
• I found by chance this excellent answer to a question I had asked myself many years ago but for which I never got to devote any thinking or even googling: Why a C# struct cannot be inherited?

  Technically, being a "value type" means that the entire struct - all of it's contents - are (usually) stored wherever you have a variable or member of that type. As a local variable or function parameter, that means on the stack. For member variables, that means stored entirely as part of the object. That means that if you allowed structs to have subtypes with more members, anything storing that struct type would take up a variable amount of memory based on which subtype it ended up containing, which would be an allocation nightmare. An object of a given class would no longer have a constant, known size at compile time and the same would be true for stack frames of any method call. This does not happen for objects, which have storage allocated on the heap and instead have constant-sized references to that storage on the stack or inside other objects.

Closure in a Loop Revisited (C# 5.0)

I've come across something today that has prompted me to write a fast post to update this previous one.

To my surprise, I read here that the way closures trapping loop variables work is being changed in C# 5.0. I felt quite shocked, as the way it works now is the correct way. I don't mind how many developers find it confusing (of course I found it terribly confusing before I fully grasped the idea), Programming is not an easy art, and it demands from artists (us) practice, effort and devotion. So if you're using closures you should know that Closures trap Variables, not values, meaning that if your loop is updating the variable, it's also updated for the closure(s) that have trapped it.

Seeking to learn more about this change I found this post by the very Eric Lippert

In C# 5, the loop variable of a foreach will be logically inside the loop, and therefore closures will close over a fresh copy of the variable each time. The "for" loop will not be changed. We return you now to our original article.

OK, good it's changing only for the foreach loop, not for for loops. I still find it unnecessary, but have to admit that the arguments given by Eric makes some good sense. However, probably this adds even more confusion to the issue:

• On one side, people who knew how closures and loops worked before, will learn about this new "feature" and will be aware of things working differently between for and foreach, so no problem with them (us)
• On the other side, people who were confused about closures and loops before, probably won't learn about this new feature, and suddenly, they can painfully hit a case where replacing a foreach with a for will change the behaviour of their code

Update 2012/05/29 I've just found this complementary question

Command Query Separation and Method Chaining

There are many Programming Principles that may seem simple when you first read about them, but when it's time to put them into practice it's a different story. Some principles can apparently clash with others, others are just purely ridiculous when taken to the extreme (Single Responsibility can end up in a class explosion anti-pattern with too many classes with maybe just one method). Some do only apply to certain cases, and don't make sense if used as a rule of thumb (the Law of Demeter is still confusing to me in many cases).

One case that has had me thinking in several occasions is the Command Query Separation vs Method Chaining (Fluent interfaces) one. In principle it would seem like Method Chaining violates the Query Command Separation principle, as you can read here. Yes, you have commands (methods that perform and action and change state) that are also queries (they return values). The thing is, is this really a problem?. I think the main idea underlying this principle (at least the main idea in the wikipedia entry) is: asking a question should not change the answer. Yes, that's also for me the main point, querying data should not modify state. This said, I think that the fact that a command returns state as "an extra" should not be a problem. For example, let's think this in terms of DOM manipulation:

$("#miDiv").append(htmlNodes).addClass("updated");

It's clear that append there has been thought as a command, not as a query that has the side effect of modifying state. You don't use append to obtain the same element again, it's absurd, you use it to modify the element, an as an extra you decide to return the element to facilitate writing cleaner code. So, to me this is not really a violation of the CQS principle.

On the other side, I pretty much agree with what what Fowler says "I prefer to follow this principle when I can, but I'm prepared to break it to get my pop.". It's interesting to note the mention that he does to the Stack class, it also called my attention that Java iterators break the principle (next advances and returns the new value). On the contrary, .Net enumerators don't break the principle, we've got a MoveNext "Command" method, and a Current "Query" property.

We should also have present that there are other cases where this principle doesn't hold simply cause the world that we're trying to model does not follow those rules. Let's imagine a "Person" object with a "GetCurrentThoughts" methods. Calling this method could modify the internal state of the Person, by increasing his "Tiredness" property...

There's another topic that some times comes to my mind related to these matters, the Read Only Property (getter) vs Method discussion. This is because I found sometimes among the list of rules to discern if something should be one thing or the other, that Properties should not have side effects, that is, retrieving a property should not change the state of the object. Well, that is quite useless, cause based on the CQS principle, a method that retrieves a value is a command, and as such should not have side effects either. Regarding this, another interesting point is that properties should not return new objects, you should use a method for that. I also recommend reading this discussion about DateTime.Now being a property instead of a method.