Saturday 28 May 2016

Static Methods in JavaScript

I wrote in the past that I found it confusing (in the JavaScript world) how some Object methods had been made static (Object.getOwnPropertyNames) and others made instance methods (Object.prototype.hasOwnProperty). I gave some reasons at the time, but I think I missed a pretty important one, probably cause in other languages it does not apply.

One main reason to do so, myClass.method(instanceOfMyClass) rather than instanceOfMyClass.method() is if we want to prevent overriding. One object could override the "inherited" method by directly setting it in itself, or somewhere else in the prototype chain. If you are using the "static" form, you can not override it for some selected objects, and if you set it as non writable, you can not override at all. When it is an instance method, you can set it as non writable to avoid changes to the original one, but that does not prevent it from getting added the overriden method somewhere down the prototype chain or directly in the instance.

In order to ensure that your code is calling the original instance method and not an override will drive people to write code like this:
Object.prototype.hasOwnProperty.call(myObj);
to avoid surprises in case someone has redefined hasOwnProperty in myObj.

In C# you just avoid the possibilities of overriding by not setting as virtual the method that you want to protect. Well, this is partially true, cause someone can hide the inherited method by declaring it as new. In that case, if you do the call through a variable declared of the base type you will for sure call the base method (irrespective of the real run time type, as the method resolution is done at compile time). If you use a variable of the derived class performing the hiding, the call (also set at compile time) will go to the "redefined" method in the derived one, skipping the hidden method. You can read more here

Saturday 21 May 2016

Scope of Iteration Variable

The confusion with Closures inside loops and variables is well known, and I wrote about it years ago. When Microsoft decided to avoid this "problem" by making the scope of the iteration variable in foreach loops local to each iteration (but keeping the iteration variable in for loops global to the whole loop) I found it pretty confusing. In order to avoid a problem that only happened due to an incomplete understanding of closures, you change what I understood as the normal scope of a variable and make for and foreach loops behave differently. Let's see an example:

 var actions = new List<Action>();
  
  foreach (var i in Enumerable.Range(0,5))
  {
   actions.Add(() => Console.WriteLine(i));
  }
  
  foreach(var action in actions)
  {
   action();
  }
  
  Console.WriteLine("---------------------");
  actions = new List<Action>();
  
  for (var i=0; i<5; i++)
  {
   actions.Add(() => Console.WriteLine(i));
  }
  
  foreach(var action in actions)
  {
   action();
  }

The above code prints:

Reading about ES6, let and the scope of the iteration variable, I've seen that they have adopted the same approach that Microsoft took with the foreach loop. In ES6 loops (for, for-in and for-of) the scope of a let variable is the iteration itself, not the whole loop. It seems they have done this to avoid the "problem" with closures. It is explained here.
On each iteration, the loop creates a new variable and initializes it to the value of the variable with the same name from the previous iteration..
Let's see an example:

let items = [0, 1, 2, 3, 4];
let actions = [];
for (let i of items){
 actions.push(() => console.log(i));
}

for (let action of actions){
 action();
}

console.log("---------------------");
actions = [];

for (let i = 0; i<5; i++){
 actions.push(() => console.log(i));
}
for (let action of actions){
 action();
}

The above code prints:

Honestly, I find it counterintuitive that the scope behaves like that, but well, it's just a new rule that you have to learn. At least in ES6 the behaviour is the same for all loops, not like in C#, where for and foreach behave differently.

Friday 13 May 2016

Variadic Functions

The recently released node.js 6.0 supports almost all the ES6 features, which is great news. It's pretty nice to be able to write some ES6 code and run it with no need of a transpiler nor anything. This has prompted me into trying to learn all the new ES6 features. The new way to work with variadic functions (yep, this is one of those nice terms to drop in the middle of some technical discussion to gain some recognition :-D) is pretty sweet.

You use the "..." syntax (when used in the function signature it's the rest operator) to declare a function of variable arity. This way you get an array with that variable number of arguments. You use it like this:

function sortAndFormat(...items){
	return "[" + items.sort().join("_") + "]";
}

console.log(sortAndFormat("Xixon", "Paris", "Toulouse", "Berlin"));

Now comes the interesting part. What if the parameters that we want to pass to the function are already in an array? We have to use the "..." syntax in the function invocation (now it works as the spread operator, that is nicely used in many other circunstances).

var cities = ["Xixon", "Paris", "Toulouse", "Berlin"];

console.log(sortAndFormat(...cities));

When a function is variadic the ES compiler will wrap the parameters being passed in an array when doing the call. If we are using spread and rest we are doing 2 inverse operations, so one could think if maybe the compiler will optimize it and do nothing, but it doesn't seem so:

var things = ["a", "e", "o"];
function checkReferences(...items){
	if (items === things){
		console.log("same reference");
	}
	else{
		console.log("different references");
	}
}

checkReferences(...things);
//prints different references

Coming back to the rest-spread combination, during the function invocation the spread operator will turn the array into multiple parameters, that because of the the rest operator in the function declaration will be received in an array. This is quite different from how it is done in C# (and I guess also in Java). If a method uses the params keyword (variadic method) and we have our arguments in an array, we can invoke it directly, without any extra step.


	public static string SortAndFormat(params String[] items)
	{
		return "[" + String.Join("_", items.OrderBy(it => it)) + "]";
	}

var cities = new string[]{Xixon", "Paris", "Toulouse", "Berlin"};
SortAndFormat(cities); 

When invoking a method that has the params keyword, the C# compiler will add code to put the arguments into an array to pass to that method, except if there is a single argument and it is an Array of the arguments type. In that case the compiler assumes that you want to use each element of the array as an argument.

This way of working leads to a problematic case in C#. Let's say a method expects n objects as parameters and in one invocation we want to pass it an array of object as its unique parameter. In that case we have to do some trick. As in this case the compiler will not do the extra wrapping himself, we can wrap that Object[] into another [] ourselves. Another option is to cast that Object[] as Object, so that in that case the compiler will add the extra wrapping code. I already posted about this a few years ago

Console.WriteLine(HowManyArrays(new Object[]{stringAr}));
		Console.WriteLine(HowManyArrays((Object)stringAr));

For that case in ES6, you just will pass the array, skipping the use of the spread operator.

console.log(howManyArrays([]));

Both languages use an inverse approach. In ES6, due to the existence of the spread operator it's very simple to turn an array into arguments, so if that's the behaviour you want you have to do it explicit by using the operator. In C#, the lack of such operator forces the compiler to decide by default that if you are passing an array it means that you want to pass its items, otherwise there would be no way to do it.

This rest-spread functionality is making the use of my beloved arguments pseudoarray mainly unnecessary. It seems they are trying to kill an Optimization killer

Tuesday 3 May 2016

Suspend Process

Probably you already know that the almighty ProcessExplorer allows you to suspend and resume a Windows process. As I needed to use this feature the other day, I wondered how it would be implemented. Some googling brought some interesting information.

First, there is neither a .Net Process.Suspend (or Resume) method (but you have Process.Start and Process.Kill) nor a Win32 SuspendProcess function (but you have CreateProcess and TerminateProcess). So what? The solution that I have found here and here is suspending all the threads in the process. Makes sense, windows schedules at the thread level, so if you suspend all the threads in the process, the whole process is suspended. From the code in both links you can see that we have to resort to PInvoke, because we can not suspend threads in another process directly from .Net. This brings to mind one thing, if you have ever been tempted to use the Thread.Suspend .Net method you'll have noticed that it's deprecated and discouraged. The reason for this is that if you suspend a thread that holds some resources that another thread is waiting for, you have a deadlock. Rather than this you need to use something more cooperative. Notice also that though Thread.Abort is not deprecated it's also discouraged for the same reason.

The difference is that suspending and resuming all threads in one process is one exception to that rule. As all threads get suspended there's not problem with one of them waiting forever for something hold by another, cause all of them are waiting. If then you resume them all, there's no problem. I have read some comments on stackoverflow against this technique because of the possibility of deadlocks, but as some replies say, there's no reason for that. This question mentions that, and also mentions an undocumented function that can be used to suspend a process directly (NtSuspendProcess in ntdll.dll). Seems to be used by ProcessExplorer, but being undocumented (and hence prone to change in a new OS version) I would try to avoid it.

One fundamental point to operate on threads belonging to another process is that Thread Ids are unique at the machine level (though they get reused over time), not just at the process level (you can confirm it here