Friday, 18 August 2017

Covariance and Contravariance in Delegates

Delegates covariance and contravariance is a rather confusing topic and I'm not going to put any theory here, you can check any MSDN or stackoverflow response for that, I'll just put here a fast, personal reference. For an excellent approach to Variance in Programming languages, you should read this.
Short ago I talked about Converting from one delegate type to another different delegate type with the same signature. Covariance and contravariance in Delegates is a different topic, but we'll see that in one case it saves us having to do that conversion.

Since C# 2.0 covariance and contravariance applies to the rules that dictate that you can create a delegate of a certain type that points to a method of a certain return type and signature. We no longer need a perfect match between return types and the signature. You can read about it in Variance in Delegates.

What C# 4 brought to the table was covariance and contravariance between related generic delegates. Basically, now you have a relation between Func<Animal> and Func<Cat> and between Action<Cat> and Action<Animal>. It's explained in Variance in Generic and Non-Generic Delegates

I'll put some examples here for easy reference

Delegate Covariance (for return types)

If we have these custom delegate types and method:

  public delegate Animal CreateAnimalDelegate();
  public delegate Cat CreateCatDelegate();
    
  public static Cat CreateCat(){
   return new Cat();
  }

Since C# 2.0 (one MSDN article mentions 3.0, it's wrong) we can do this, bind a delegate type (returning an Animal) to a method returning a more derived type (Cat):

CreateAnimalDelegate animalCreator = CreateCat;

If we are using generic delegates we can do the same (this is not related to the out keyword introduced in C# 4), here this continues to be delegate binding.

Func<Animal> animalCreatorFunc = CreateCat;

C# 4 brought something new, you can point a variable of a certain delegate type to an instance of a delegate of a different but related type. From MSDN

In .NET Framework 4 or later you can enable implicit conversion between delegates, so that generic delegates that have different types specified by generic type parameters can be assigned to each other, if the types are inherited from each other as required by variance.

//so thanks to C# 4 I can do this assignment of a different delegate type, there is no conversion it's just type compability
Func<Cat> catCreatorFunc = CreateCat;
Func<Animal> animalCreatorFunc = catCreatorFunc;


//so in C# 4 there is type compability, but not really inheritance ("is" works, but "IsSubclassOf" does not)
Console.WriteLine("catCreatorFunc " + ((catCreatorFunc is Func<Animal>)? "IS" : "IS NOT" ) + " Func<Animal>"); //IS 
Console.WriteLine("Func<Cat> " + ((typeof(Func<Cat>).IsSubclassOf(typeof(Func<Animal>)))? "IS" : "IS NOT" ) + " Func<Animal>"); //IS NOT!!!

As you see in the example I can point a Func<Animal> to a Func<Cat>, it's as if they were in an inheritance hierarchy, but it's not really the case, cause while the is operator will tell us that Func<Cat> is a Func<Animal>, the IsSubclassOf will tell us that no inheritance exists.

All in all Covariance for return types seems pretty natural, same as we can do Animal an = new Cat(); , we can do Func<Animal> fAn = new Func<Cat>...;

Delegate Contravariance (for arguments)

Delegate Contravariance seems a bit less natural, cause basically we can do: Action<Cat> aCat = new Action<Animal>.... So it seems we are reversing the way we use type compability (a Cat is an Animal for sure, but here we seem to say that an Animal is a Cat). If we think that this applies to parameters it makes total sense. We invoke aCat passing a Cat to it. aCat points now to a function that expects an Animal, so if it receives a Cat it will behave nicely.

I'm putting here the equivalent contravariant samples for the ones above

public delegate void ManageAnimalDelegate(Animal an);
public delegate void ManageCatDelegate(Cat cat);
    
public static void ManageAnimal(Animal an){
 
}

Bind a delegate type (expecting a Cat) to a method expecting a less derived type (Animal):

ManageCatDelegate catManager = ManageAnimal;

If we are using generic delegates we can do the same (this is not related to the out keyword introduced in C# 4), here this continues to be delegate binding.

Action<Cat> catManagerAction = ManageAnimal; //this one looks a bit odd cause we are sort of doing Cat = Animal;

And what was added in C# 4

Action<Animal> animalManagerAction = ManageAnimal;
Action<Cat> catManagerAction = animalManagerAction;

Console.WriteLine("animalManagerAction " + ((animalManagerAction is Action<Cat>) ? "IS" : "IS NOT" ) + " Action<Cat>"); //IS
Console.WriteLine("Action<Animal> " + ((typeof(Action<Animal>).IsSubclassOf(typeof(Action<Cat>)))? "IS" : "IS NOT" ) + " Action<Cat>"); //IS NOT!!!

To finish this article, I'll mention that while return type covariance applies to delegates, unfortunately (in C#) it does not apply to overriden methods in a derived class (Java has support for this since a long while). For contravariant arguments, again it applies only to delegates. The feature is not available for methods in hardly any language.
To my surprise, I learn that Eiffel supports Covariance in method arguments

Thursday, 17 August 2017

After the Wedding

When I first watched After the Wedding some years ago, I quite liked it, but it was last week, when watching it for second time, when I really realised how excellent this film is. Susanne Bier is such a great director and (notice that I have not watched all her films, I particularly miss Open Hearts) this is so far my favorite.

The story (co-written by Susanne) is rather imaginative and becomes more and more powerful as it develops. It's always amazed me that citizens of happy and well-functioning societies like Denmark or Sweden have such a capacity to create dark and compelling dramas (the Scandinavian Noir of Camilla Lacberg and Asa Larsson particularly delight me due to those characters living sad, complex, tormeted existences). In After the Wedding we have these 2 characters meeting again "as if by chance" after 20 years of neglect. First there's some anger, then those old feelings that will never disappear and the maturity that time gives us as such a beautiful present, will heal the pain and make things move on. This short conversation (it's not a literal transcription) describes with such sharpness how easy it is to spoil our lives:

  • - Why didn't you come back?
  • - Cause I thought you would end up following me
  • - Why didn't you follow me?
  • - Cause I thought you would come back

The most impressive moment in the film is when the husband, this strong and succesful man that had kept his terminal illness hidden from his love ones and seemed to be putting up with it so well finally crumbles. At the moment when the physical damage starts to show and the end of the "game" (our only game) becomes a too close certitude, the strong man collapses in tears, embraced to his loving wife and crying "I don't want to die". A powerful reminder of how temporal all we have, all we are, is. A reminder of how precious every second is, of how costly any unsaid word or unexpressed feeling is.

The leading actor, Mads Mikkelsen is sort of a must in most of popular Danish films. His facial expression is pretty astonishing, sometimes it's difficult to know if he's laughing, crying or both. I've recently watched another rather good film of him, The Hunt.

Monday, 31 July 2017

Delegate Types Conversions

The (non) equivalence between different delegates with the same signature can be a source of confusion. I'm not going to talk in this post about another related source of confusion with delegates, Covariance and Contravariance (pointing delegates to methods with "similar" signatures), probably I'll dedicate another short post to that topic.

Since the advent of the Func and Action generic kind of delegates, it's quite unusual (and advised against) to create your own delegate types, but you will still find them, mainly coming from old code. So let's say that you want to assign an instance of a custom delegate type to one of the generic ones, like this:

delegate string FormatterDelegate(string st);
...
class Formatter
 {
  private string formatItem;
  
  public Formatter(string formatItem)
  {
   this.formatItem = formatItem;
  }
  public string Wrap(string st)
  {
   return this.formatItem + st + this.formatItem;
  }
}

var formatter = new Formatter("--");

FormatterDelegate formatterDeleg = formatter.Wrap;

//this line won't compile
Func<string, string> formatterDeleg2 = formatterDeleg;

The last line will not compile. Though their signatures are the same (receive a string an return a string), Func<string, string> and FormatterDelegate are completely different types and you can not assign one to another. So the obvious solution is to create a Func<string, string> delegate that calls to FormatterDelegate. I used to do this:

Option 1:

Func<string, string> formatterDeleg2 = (st) => formatterDeleg(st);

Somehow the other day I came across some discussions ([1] and [2]) on this topic and there are other similar ways to address this issue.

Option 2

Func<string, string> formatterDeleg2 = new Func<string, string>(formatterDeleg);

Option 3

Func<string, string> formatterDeleg2 = formatterDeleg.Invoke;

Option 3 made quite sense to me, but I have to admit that option 2 pretty surprised me. I didn't know that the compiler allowed to pass a delegate to a delegate constructor. In the end the compiler generates the same IL code for option 2 and option 3.

Both cases are similar in performance terms to Option 1. In all of them the call to the code in the original delegate goes through an additional level of indirection. This is clear for Option 1, where you are invoking an anonymous method that in turn calls to the original delegate. In Options 2 and 3 the MethodInfo of the Func delegate will point to the Invoke method of the original delegate, so you also have a "double hop". Option 1 creates a closure to hold the reference to the first delegate, so in the end will have some extra (but minimum) cost.

Option 4

. In the discussion they came up with a different technique that avoids the extra level of indirection:

formatterDeleg2 = (Func<string, string>) Delegate.CreateDelegate(typeof(Func<string, string>), formatterDeleg.Target, formatterDeleg.Method);

With Option 4 you directly assign the method referenced from the original delegate to the new delegate, so the indirection is avoided. Notice that they mention that this will cause problems with multicast delegates.

I was going to put up some test code as a gist in github, but it is down.

Friday, 28 July 2017

Enmerable/Iterable Comparison

I've been revisiting the way C#, JavaScript and Java approach Iteration (Enumeration in C# jargon), so I'll dump here a short summary.

The basis is the same for the 3 languages. In C#/Java you have a class that implements the IEnumerable/Iterable protocol providing you access to an IEnumerator/Iterator object that takes care of the iteration. In JavaScript your object implements the Iterable protocol by featuring a [Symbol.iterator] property that returns an object conforming to the Iterator protocol.

The main difference stems from the methods provided by the Iterator (Enumerator) object. Most times you should not be concerned about these differences, as you will be just using the specific loop structure provided by each language:
foreach (it in enumerable)
for(o : iterable)
for (variable of iterable)
But if you are using your iterable differently you should take some more things into account.

C#. You advance your position in the Enumerator by calling the MoveNext method, that returns false if it has passed the end of the collection. To access the current element you use the Current property, that will return "an undefined value" (which is quite an open and confusing idea) if you are either before the first element (you've never called MoveNext) or after the last element (the last MoveNext returned false)

JavaScript. Your iterator just provides you with a next method, that returns a [done, value] pair and moves to the following position.

Java. The iterator provides a hasNext method, that returns false if you are positioned at the last element, and a next method that moves to the next position and returns its value. If you were already at the last element, next will throw a NoSuchElementException.

These iterators present similarities and differences. C# and JavaScript are pretty similar. As we've seen both of them have a method (MoveNext/next) that advances the iterator if possible and returns a boolean indicating if it has reached the end. If the end has not been reached, in C# we access the current element via the Current property while in JavaScript that value has also been returned in the next method. I like the idea of being able to access the current element through a property.

Java is quite a bit different. I find the haveNext method rather strange. It tells you if there is a next element, but does not gather it (in C# MoveNext does not return the next element as such, but is supposed to assign it to the field backing the Current property). So after the hasNext you will have to call next to really obtain the element. On one side, this means that if there are several threads accessing the iterator you have to put hasNext and next inside a critical section, on the other side, depending on your iterator, checking for the existance of a next item and obtaining it could be costly operations, so there is a sort of redundancy. The iterator could internally obtain and cache the value when checking for existence of the value, but maybe the caching is not the intended behaviour. So all in all I find the Java design a bit odd.

InHuman Rights

This week I've been reminded of how stupid some "Human Rights" organizations can be. After the Iraki Army finally managed to liberate Mosul from the Daesh monstrosity, Human Rights Watch denounced that the Iraki forces had mistreated and executed Daesh "militants" (I hate when the media calls these beasts "militants" it's a word that seems to normalize them, they are not "militants", they are fascists beasts). OK, so the Iraki forces have executed some "individuals" that were part of an "organization" that rapes and sells women as slaves, that throws homosexuals from the roofs, that chops people's heads or burn them alive because of being infidels... So what? Should we just put them in prison waiting for them to be rehabilitated? Bullshit, we must punish them in accordance to their crimes, so of course they must be executed, and before that we should make them suffer at least a bit of the pain that they have caused to others. Yes, I'm saying what you think to have understood, I think that Daesh members that have been captured alive should be physically punished (yeah, I'm trying avoid the word "torture" to not sound so "aggressive"), before being executed, "eye for an eye...". This reminds me of the nice treatment given by Nasser to Sayyid Qutb one prominent IslamooFascist that has been a source of inspiration for Islamists worlwide.

The difference between people that like me defend the execution (and previous physical punishment) of these monsters, and Human Rights organizations that decide to defend these beasts, is our conception of Humanity. I consider myself an Humanist, and I think of "Human" as a moral attribute, an attribute that can be lost due to our inhuman actions. Human Rights organizations think of "Human" just as a biological attribute that as such can not be lost (a Human can not be converted into a dog, so he will ever be a Human regardless of his actions and hence will always be granted with Human rights, whatever he has done).

For me, when a Human being commits brutal acts against other living beings (humans or animals), these inhuman actions deprive him of his Humanity, and the moral rules that we use when dealing with other humans (and should be applied also to animals) should no longer apply. At that point that individual must be punished with as much vehemence as those affected by his crimes (or the society in general) decide. This punishment can involve for sure execution, but also different levels physical and/or psycological punishment.

Last year there was an opinion poll in France (I think French people love polls, you constantly find in the news headers like "60% of French people think that...") where a big percentage of the participants said to agree with the idea of torturing Islamist Terrorists to obtain information (this was just after the capture of the Salah Abdeslam bastard). Of course I agree with the idea of subjecting Abdeslam (or any Salafist scum) to very hard physical punishments, but not just for obtaining information, but for the sake of justice. I'm fed up of the idea of "rehabilitation". Sometimes people commit small crimes out of real need, and for sure these people must be helped. Other times people just make "acceptable" errors, that's an essential part of our human condition. In these cases the ideas of rehabilitation and punishment should go together. Be deprived of your freedom for some time as a punishment, and leverage that time to help you make up your mind and choose a different path. But when the crime is too brutal, too cruel, I don't think rehabilitation should play any role, the only thing that matters is punishment.

Friday, 14 July 2017

The Autopsy of Jane Doe

It has passed almost one year since I watched The Witch, and my attitude towards horror films has not changed, I continue to be no particularly interested on "Paranormal" Horror, but again, as with The Witch, The American Cosmograph has given me the opportunity to watch a really good one, The Autopsy of Jane Doe.

One father and son run proudly and professionally an "Autopsy business". One evening the police brings them a new "client", a young, beautiful, unidentified (hence the "Jane Doe" thing) woman found dead in unknown circunstances. They start the examination, and as it advances more an more odd findings stack up until the first paranormal events start. So far, the film was a bit gore, now it turns violent and claustrophobic, with some good jump scares. To round it off they manage to give it a nice source to all this supernatural mess (OK, it's paranormal stuff, don't thik of a rational explanation, but the idea is cool). Indeed, this is one more point that makes me relate this film and The Witch

The acting is pretty good, particularly Brian Cox, and the 90 minutes of the film pass too fast. There is one of those moments of 5 seconds when the screen goes completely black (there's a blackout), that is particularly good when you are watching the film in the huge screen of a cinema.

All in all, a very good cinema, that for sure will be on top ten of 2017 Horror films and that you should watch.

Friday, 7 July 2017

ES6 Proxies and getPrototypeOf

The other day, somehow came to my mind an old post about static methods in JavaScript, and I thought that similar to the "avoid overriding" reason that I mention in that post, another use case would be to prevent operations from being intercepted by a proxy. I immediately thought of key actions like getPrototypeOf as an action that is better to be sure that the real method is being called and not a replacement, so it's much better to have it as a static method than as an instance method. So to my surprise I found out that the Proxy API provides a trap for getPrototypeOf, that indeed intercepts all these operations:

  • Object.getPrototypeOf()
  • Reflect.getPrototypeOf()
  • __proto__
  • Object.prototype.isPrototypeOf()
  • instanceof

Seeing that list I thought, OK, it intercepts all those cases, but will it intercept the case when the runtime is traversing the prototype chain of an object?.

I've done a short test, and seems like the traversal of the prototype chain when the runtime searches for an item is not affected by the proxy trap.


class Person{
 constructor(name){
  this.name = name;
 }
 
 sayHi(){
  return "Hello I'm " + this.name;
 } 
}
 
let p1 = new Person("Francois");

let proxiedP1 = new Proxy(p1, {
  getPrototypeOf(target) {
 return null;
  }
});

console.log("- Operations with proxiedP1");

console.log("proxiedP1 instanceof Person: " + (proxiedP1 instanceof Person));
//false

proto = Reflect.getPrototypeOf(proxiedP1);
console.log("proto is " + (proto === null ? "NULL" : "NOT NULL"));
//proto is NULL


//INTERESTING, proxying getPrototypeOf does not have an effect in how the runtime itself gets access to the prototype chain, so the sayHi method continues to work, even if instanceof is now telling me that proxiedP1 is not a Person anymore
console.log(proxiedP1.sayHi());
//works fine

So if you run the code above you'll get that the internal prototype [[Prototype]] of proxiedP1 is null and that it is not an instance of Person, but the call to sayHi, that is not directly attached to the p1 object, but to its [[Prototype]], will work fine! So officially you are not a Person, but in fact you are...

I find the existance of this trap like a source of confusion, but well, you can read about some use case here.

This has raised some questions in my head. From the programmer perspective the access to a method in JavaScript is not based on Method Dispatch or Message Sending, it's just a property lookup. That property lookup just returns a function and then it's invoked (if it it does not exist the runtime will follow up the prototype chain to find it). I assumed that at the lower level it would be implemented like that, but this would means that the addition of proxies would have introduced a sort of conditional to any property access in any object in the system. The runtime would have to check if the object is a proxy and has a get trap to invoke that trap or just do the normal access. If this were this way, the introduction of proxies in ES6 engines would have had performance implications for any code (whether it uses proxies or not), so obviously there has to be much more to it.