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.

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.

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.

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.

Generics and Dynamic

Time ago I saw somewhere a fragment of code that rather confused me. It was a line where a generic method was receiving dynamic as type parameter. "dynamic" is something at the C# compiler level, but at the MSIL level it does not exist, it just gets translated into callsite magic for accessing to its methods and properties. So, if you run this code:

  public static void DoSomething<T>()
  {
   Console.WriteLine("type: " + typeof(T).FullName);
  }
  
  static void Main(string[] args)
  {
    DoSomething<String>();
   
    DoSomething<Object>(); 
   
    DoSomething<dynamic>();
   
   //Output:
   // type: System.String
   // type: System.Object
   // type: System.Object
 }

You can see the passing dynamic or Object is just the same, in the method you are receiving T as an Object. If you decompile it and check the MSIL you'll see indeed the compiler is just replacing dynamic by Object in the call.

So from the point of view of the invoked method "dynamic" has no particular meaning, it's from the caller side where it can add semantic value to write DoSomething<dynamic> rather than DoSomething<Object>.

Another related case is when a method returns generic type of dynamic. For example, in Dapper we have this method:

public static IEnumerable<dynamic> Query (this IDbConnection cnn, string sql, object param = null, SqlTransaction transaction ...

Again, at the MSIL that dynamic is just an Object, you can check the MSIL:

Here the semantic value of using dynamic is particularly powerful. It's telling you that the method is returning an object that whatever its type, contains all the fields that you expect and so you can access them without a problem. You can consume it like this:

var rows = connection.Query(...); 

If they had just signed the method as returning IEnumerable<Object> you could write something like this:

IEnumerable<dynamic> rows = connection.Query(...); 

But obviously it's pretty much more semantic to have expressed this "duck typing" in the signature.

By the way, this Query method indeed returns DapperRow objects (a class implementing IDynamicMetaObjectProvider). One could think why they don't just return an anonymous type (then it's going to be accessed via dynamic anyway). One reason is performance, with an anonymous type the dynamic access would be using a Reflection (with a cache mechanism, so it works faster than normal Reflection, but it's Reflection anyway), a type implementing IDyamicMetaObjectProvider implements itmself the access and dispatch rules, so it should be faster. But there is another more fundamental reason, based on what you can read here

Anonymous objects are internal, which means their members are very restricted outside of the assembly that declares them. dynamic respects accessibility, so pretends not to be able to see those members.

Notice that when you use Reflection you can decide to ask access to non public items, but dynamic uses Reflection "as a good guy", trying to access only public items, so for this case where Dapper is in an assembly and your code in another, Anonymous Types + dynamic is not an option. On the contrary, for code living in the same assembly, like the one below, it's a good option.

static dynamic CreateObject()
{
 
 return new {Name="Francois"};
 
}
  
static void Main(string[] args)
{
 dynamic o1 = CreateObject();
 Console.WriteLine(o1.Name);
}