Html Select and Options

I've been doing some web development lately, after a really long time disconnected from that. It's a simple internal application and I've decided to use Vanilla js rather than going through the long and painful process of relearning Angular or learning Vue (React is not an option, I had looked into it time ago and the Hooks thing seemed absolutely ridiculous to me).

Using Vanilla js in a sort of small SPA has given me the feeling of understanding and controlling what I'm doing, something that I did not have with Angular. The thing is that looking into how to populate a select element I've come through something pretty interesting. This answer already shows something interesting. As with any other html element, they create the option elements with document.createElement() and set its different properties, what is interesting is that the HtmlSelectElement provides an add() method to add the options, so we can use it rather than the standard appendChild() method.

let cities = ["Paris", "Vienna", "Xixon"];
let selectElement = document.getElementById("usersSelect");
for (const city of cities) {
	let op = document.createElement("option");
	op.name = city;
	op.value = city:
	selectElement.add(op);
}

What is even more interesting, is that we can create the option element using the Option constructor

let cities = ["Paris", "Vienna", "Xixon"];
let selectElement = document.getElementById("usersSelect");
for (const city of cities) {
	selectElement.add(new Option(city, city));
}

I've been using document.createElement for centuries, and then at some point in time, thanks to the MDN documentation I found out that each of the different html elements corresponds with a class inheriting from HTMLElement. So we have HTMLDivElement, HTMLSelectElement, HTMLOptionElement, etc, etc. So, first, for creating an option, why do we use an Option constructor rather than HTMLOptionElement?, and second, why don't we create other html elements invoking HTMLDivElement, etc, rather than document.createElement?

Well, if we try to invoke a new HTMLOptionElement() (or any other new HTMLxxxElement()) we get an error: Uncaught TypeError: Illegal constructor. If we look into the MDN documentation, each HTMLxxxElement is described as an interface. This seems odd, given that in JavaScript there's not syntax for defining interfaces, so in the end it seems like an "interface" is a class which constructor throws an error when being invoked (so it's not directly instantiable). Though we can not directly invoke the HTMLxxxElement constructor, the constructor property of objects created with document.createElement() will point to the corresponding function, and of course instanceof will work fine. I mean:

let d1 = document.createElement("div");
d1.constructor.name
"HTMLDivElement" 

d1.constructor === HTMLDivElement
true

d1 instance of HTMLDivElement
true

Creating and option either with new Option() or document.createElement("option") has exactly the same effect. The instanceof operator applied to objects created that way returns true both for Option and for HTMLOptionElement, but in both cases the instances constructor property points to the HTMLOptionElement function, not to the Option function. So the Option function is considered a constructor, but a particular one. It can be invoked with new (in JavaScript any 'non arrow function' can be invoked with new and returns an object in such case) and has been designed to initialize the object that it returns, but that object is not an instance of Option, but an instance of HtmlOptionElement.

let op1 = new Option("k", "v");
undefined
op1 instanceof Option;
true
op1 instanceof HTMLOptionElement;
true
op1.constructor === Option
false
op1.constructor === HTMLOptionElement
true

let op2 = document.createElement("option");
undefined
op2 instanceof Option
true
op2 instanceof HTMLOptionElement
true
op2.constructor === Option
false
op2.constructor === HTMLOptionElement 
true

Promises vs Observables

Reactive Extensions (I've only used them in JavaScript/TypeScript with rxjs) is a really powerful tool and the more one plays with them more aware one becomes. Their aim is making easy to work with push streams (sequences) of data (I had given a classification of streams types here). It gives you so much power when compared to basic/classic event listeners.

On the other side, when working with an asynchronous operation that returns just once (it can return a single value or a collection, but it returns it just once) returning a Promise and using async/await moves you into a world miles ahead of the classic callback paradigm used for continuing asynchronous operations.

From the above, it would seem clear that we'll use Observables or Promises + async + await depending on whether we have multiple data or single data. But then, you find that the Angular HttpClient returns an Observable rather than a Promise and it seems odd. Even worse, if understanding how the magic of async/await and Promises (or Tasks in .Net) was not an easy endeavor for you, it hurts hard to read people saying that Promises are no longer cool and only Observables rule... what the fuck!?

There are many articles comparing Promises and Observables, this one is particularly good. You'll find also many discussions about why even when dealing only with a single value Observables are supposed to be always superior to Promises, and you'll find many disidents, like me :-). Observables can be cancelled and they are lazy, that's why even for a single data operation like an http request, they are supposed to be superior. That's true and that's false. Let me explain.

For those situations where you could need to cancel the http request, or you want to set it but run it lazily, yes, returning and Observable is a better option, but how often do you need any of those 2 features for a http request? Honestly, I hardly can think of a single case where I've needed that... On the other side, even after becoming familiar with pipe, flatmap, of... I think the cleanliness of the code that you can write with async-await lives in a different galaxy than the one you write with Observables. Let's see an example.

Let's say I have 2 async operations that I want to run sequentially, passing the result of the first one to the second one. Each operation would be like a http request, but in order to be able to run this code without depending on a server I'm just doing a sort of simulation.

function getUserId(userName:string, callback: (id:number) => void){
 let users: { [key: string]: number } = {
  anonymous: -1,
  francois: 1,
  chloe: 2
 };
 setTimeout(() => callback(users[userName] as number), 2000);
}

function getPermissions(id:number, callback: (permissions:string[]) => void){
 let permissions: { [key: number]: string[] } = {
  1: ["r", "w"],
  2: ["r"]
 };
 setTimeout(() => callback(permissions[id]), 2000);
}

Promises + async + await

I wrap each operation in a Promise returning function:

function promisifiedGetUserId(userName:string): Promise{
 return new Promise(res => getUserId(userName, res));
}

function promisifiedGetPermissions(id:number): Promise{
 return new Promise(res => getPermissions(id, res));
}

And now I can use them like this:

async function promisesTest(userName:string){
 let id = await promisifiedGetUserId(userName);
 console.log("id: " + id);

 let permissions: string[];
 if (id === -1){
  permissions = [];
 }
 else{
  permissions =  await promisifiedGetPermissions(id);
 }
 
 console.log("permissions: " + permissions.join(","));
} 

//sort of C#'s "async main"
(async () => {
 await promisesTest("francois");
 await promisesTest("anonymous");
})();

Observables

I wrap each operation in an Observable returning function:

function observableGetUserId(userName:string): Observable{
 return new Observable(observer => getUserId(userName, id => observer.next(id)));
}

function observableGetPermissions(id:number): Observable{
 return new Observable(observer => getPermissions(id, permissions => observer.next(permissions)));
}

And now I can use them like this:

function observablesTest(userName:string){
 observableGetUserId(userName).pipe(
  flatMap(id => {
   console.log("id: " + id);
   if (id === -1){
    return of([]);
   }
   else{
    return observableGetPermissions(id);
   }
  })
 ).subscribe(permissions => console.log("permissions: " + permissions.join(",")));
}

observablesTest("francois");
//observablesTest("anonymous");
 

I think the first code is way more clear and natural, don't you think? So Promises, await and async are alive and well! I've uploaded the code into a gist.

This said, I think the decision done by Angular of returning an Observable with their http client is OK. Converting that Observable to a Promise is as simple as invoking myObservable.toPromise(), so you can still do good use of async/await. At the same time, if you are in one of those cases where canceability and laziness are useful to use, that Observable is what you need, so in the end Angular is giving you the most versatile solution.

Await for completed/resolved Task/Promise

This post is complementary to this one. I've come across another difference between how async/await works in .Net/Javascript, awaiting on an already completed/resolved Task/Promise.

In C#, if you do an await on a completed Task (for example you've created it already completed with Task.FromResult), the code will continue synchronously, there is not a "jump outside the method that will be continued later". Oversimplifying it, we could say that the ContinueWith method invocation that the compiler creates under the covers checks if the Task is already completed and hence decides to call the continuation delegate in sequence. Let's see an example, notice how while in DoAsync1 there is no "jumping out", everything runs synchronous, in DoAsync2 we have the "jump out and continue later" behaviour:

static async Task<string> DoAsync1(string st)
{
Console.WriteLine("DoAsync, before await");
//Task.FromResult returns an already completed Task, this gets immediatelly and there is not an interruption of the current method and later reentrance
var res = await Task.FromResult(st.ToUpper());
Console.WriteLine("DoAsync, after await");
return res;
}

static async Task<string> DoAsync2(string st)
{
Console.WriteLine("DoAsync2, before await");
await Task.Delay(500);
Console.WriteLine("DoAsync2, after await");
return st.ToUpper();
}

Console.WriteLine("started");
Task<string> task =  DoAsync1("hi");
Console.WriteLine("after calling doAsync1");
Console.WriteLine(task.Result);

Console.WriteLine("---------------");


Console.WriteLine("going on");
task =  DoAsync2("hi");
Console.WriteLine("after calling doAsync2");
Console.WriteLine(task.Result);

// started
// DoAsync, before await
// DoAsync, after await
// after calling doAsync1
// HI
// ------------------
// going on
// DoAsync2, before await
// after calling doAsync2
// DoAsync2, after await
// HI

In Javascript the behaviour is different, even if the Promise is already resolved (Promise.resolve("a")), the "jumping out of the function" takes place anyway. Let's see an example. The behaviour of test1 and test2 functions is the same, in both cases we have that the "after invoking" runs before than the "after await" :

async function test1(){
 console.log("test1 before await");
 let res = await Promise.resolve("hi");
 console.log("test1 after await");
}

async function test2(){
 console.log("test2 before await");
 let res = await new Promise((res, rej) => {
  setTimeout(
   () => res("hi")
   , 1000);
 });
  
 console.log("test2 after await");
}

test1();
console.log("after invoking test1");

test2();
console.log("after invoking test2");


//test1 before await
//after invoking test1
//test2 before await
//after invoking test2
//test1 after await
//test2 after await

Async Await Comparison

I think the async/await pair is one of the most "revolutionary" features added to programming languages in the last years. I have to admit that when they were added to C# it took me a while to wrap my head around them, same as with the yield statement. Both cases come down to the same, a method that gets restarted at an intermediate point, a continuation, it seemed like magic until I understood all the compiler magic involved... Hopefully, the way async/await behaves in JavaScript is pretty similar, so most of the tricks you learnt in C# apply also in JavaScript, but there are some subtle differences. I'll write down here some notes on similarities and differences that I guess I'll be revisiting from time to time.

As you know async/await revolves around Tasks in C# and Promises in JavaScript. If we want to return a Task/Promise from an already existing value rather than from a really asynchronous operation (for testing for example), we can do like this:
C#: Task.FromResult("hi");
JavaScript: Promise.resolve("hi");

The previous feature is particularly useful in C# for testing. In C# you can only await for a Task, so easily creating a Task from a value can be pretty usefult. I thought it would be the same in JavaScript, but to my surprise I've realised that in Javascript you can await for any value, I mean, these 2 lines are equivalent:
let res = await Promise.resolve("hi");
let res = await "hi";

In both languages, marking a method/function as async means that the compiler magic will create a Task/Promise as soon as the method is invoked and that Task/Promise will ultimately contain the final result returned from the function or the exception thrown from it. Even if the exception is thrown before any call to await happens in the function (so it's running synchronous), it won't be available until we await for the function.

async function throwExceptionAsync(st){
 throw {message: "crashed"};
 return st.toUpperCase();
}

console.log("calling throwExceptionAsync");
prs = throwExceptionAsync("hi");
//I get here, so the exception has been wrapped in the promise
console.log("after calling throwExceptionAsync");
console.log(prs.constructor.name); //Promise
//I get the exception in the await 
try{
 res = await prs;
}
catch (ex){
 console.log("exception: " + ex.message);
}


//output:
calling throwExceptionAsync
after calling throwExceptionAsync
Promise
exception: crashed

There's a difference that I found when checking this question in stackoverflow. As I've just said, the compiler automatically creates and returns a Task/Promise for any async method. In JavaScript this Promise will resolve to the value that the function returns, and in C# we'll have a Task<Result> (or Task if the method returns nothing). This means that the code that we write in our async method must return a value, not a Task/Promise of value (as the compiler itself takes care of creating that Task/Promise). This means that in C# we have this:

private async Task<string> GetContentAsync(string url){...}

private async Task<string> FormatAsync(string url){...}

//this is good
public static async Task<string> FormatUrlContent(string url)
{
 string content = await GetContentAsync(url);
 return await FormatAsync(content);  
}

//this is not good, it won't compile:
//error CS4016: Since this is an async method, the return expression must be of type 'string' rather than 'Task<string>
public static async Task<string> FormatUrlContent(string url)
{
 string content = await GetContentAsync(url);
 return FormatAsync(content);  
}

The second method won't compile because our code is returning a Task<string>, that would get wrapped in the Task that the compiler automatically creates, so in the end we would be returning a Task<Task<String>>.

In JavaScript I was not expecting an error, just that we would get a Promise that would resolve to another Promise that would resolve to a string, but to my surprise the compiler seems to take this into account and returns a Promise that will be resolved when the internal Promis is resolved (so indeed it's doing the same as it does with a call to then that also returns a promise.

async function anotherAsyncMethod(){
 return Promise.resolve("hi");
}

prs = anotherAsyncMethod();
console.log(prs.constructor.name); //Promise
res = await prs; //this is already the string not a Promise of string
//console.log(res.constructor.name); //String
console.log(res);

There's another difference that I'd like to mention, though it's not about async/await, but about Tasks/Promises. In C#, if you want you can block your code (which in general is quite a bad idea) waiting for the result of the async call, by doing either Task.Wait() or Task.Result. In JavaScript, promises lack any blocking method, you can only access the result in a callback function provided to then() (or obviously through await magic.

TypeScript Typing

I have to admit that I'd never had any particular interest in JavaScript "superset-style" languages. I've loved JavaScript since I first understood how its base features: prototypes, object expansion and closures worked, and as over the years it has been getting more and more features, I'd never seen the point of moving to one of these "compile to javascript" languages (CoffeeScript, TypeScript...). With this in mind, my only reason to learn TypeScript seemed to be that it's becoming almost compulsory in some environments.

Well, I have to say that I'm amazed. The first beautiful surprise is that as it incorporates all the last-generation ES features, you can just use it as a "javascript version X" to "javascript version X-n" compiler. In that sense it's a nice replacement for Babel.js. It's interesting for example to see the different compiled code of a source that uses async/await. Compiling to es2016 will use a generator, compiling to es2017 will directly use async/await. Apart from this, some people will just use it as if it just were a sort of statically-typed Javascript.

This statically-typed vision is pretty limiting. You can use the language like that if you want, but indeed the "typing discipline" used by TypeScript is much more than that. You'll read in several places that TypeScript uses Duck Typing, well, from my understanding this is not correct, it uses Structural Typing. Even the TypeScript documentation does not seem to care and uses both terms as synonymous here, so I'll try to explain how I see the difference between both terms. It's normally said that Structural Typing is Compile-time Duck Typing, but I think the thing is a bit more complex. This article quite a bit of light on it.

Duck Typing. Duck Typing (like in JavaScript) only cares about the properties or methods that you are accessing (or will be accessing) at runtime. You don't define contracts (specify the type of an argument or variable), you just try to access to a property/method and if it fails you get an error. This is normally done at runtime and that's why we associate Duck Typing with dynamic languages, but it seems there are languages which compilers can do these checks at compile time: C++ and D templates

Structural Typing. This has been a pretty interesting discovery for me. You define contracts (for example the type of arguments to your method) and these contracts are checked at compile-time. In TypeScript you define these contracts via classes, interfaces or just via inline type definitions. The important thing is that contrary to what is done in C# or Java, in order to verify that contract the compiler will not check if the object is an instance of a class in which type hierarchy you can find the class or interface of the contract (this is called nominal typing, because you are checking type names). What the TypeScript compiler does is checking Type compabiliby by checking the shape (structure) of the object with the shape defined by the class or interface. If the shape matches (the object has the requested methods and properties), the contract is fullfilled, regardles of the names of the types in that object type hierarchy.

An interesting point is that with runtime Duck Typing a calling a function passing it the same object could succeed of fail depending of other factors, for example in this JavaScript code the first call works fine, but the second one throws an exception:

function getTax(item){
 if (salesSeason){
  return 0.10 * item.getSalesPrice(); 
 }
 else{
  return 0.10 * item.getPrice(); 
 }
}

var salesSeason = false;
let item = {
 name: "black jeans",
 getPrice(){return 21;}
};
getTax(item);//Works fine

salesSeason = true;
getTax(item); //throws exception, TypeError: item.getSalesPrice is not a function

However, in this TypeScript code Structural Typing will make the compiler give us errors for both calls:

interface ISalesItem{
 getPrice(): number;
 getSalesPrice(): number;
}

function getTax(item: ISalesItem){
 if (salesSeason){
  return 0.10 * item.getSalesPrice(); 
 }
 else{
  return 0.10 * item.getPrice(); 
 }
}

var salesSeason = false;
let item = {
 name: "black jeans",
 getPrice(){return 21;}
};
getTax(item); //compiler error

salesSeason = true;
getTax(item); //compiler error

Just to end this post, another beautiful idea in TypeScript is that the compiler was designed since its inception with a Language Service layer. I guess it was a quite natural decision for Anders Hejlsberg, that at that time had been working very hard on Roslyn.

MethodMissing in Javascript

If one compares ES6 to Groovy (that for me is, based on some playing with it years ago, the most expressive language that I can think of) one could spot some missing features, like methodMissing (present in many other languages) or the superclean interception via invokeMethod. The truth is that you can get both features by using proxies and a get trap.

I'll use the term "class" regardless of whether we use ES6 class syntax or the "traditional" style. Proxies looked powerful to me, but I used to see a main problem with them: having to create a proxy for each object for which I want the feature. I'd like to do it directly at the class level. Well, as everything in javascript is an object, you just have to proxy the correct object, the prototype. You'll see that people use this technique to get other features, like multiple inheritance. I've cooked a sample of how to implement method missing.

My first approach was just to wrap "MyClass.prototype" in a proxy and reassign it, like this:

let aux = MyClass.prototype;
MyClass.prototype = new Proxy(aux, {
 //your get trap here
});

This does not work because when using the class syntax, the prototype of the constructor function is neither writable nor configurable, so you can not do the reassignment. To work around it we have to create a subclass using the old syntax so that we can do the prototype reassignment. So if I have an Employee class that I want to do "method missing aware" I'll define a sort of subclass like this.

class Employee{
 //whatever
}

function EmployeeWithMethodMissing(name){
  //Employee.call(this); not allowed to call a constructor other than with new
  let emp = new Employee(name);
  Reflect.setPrototypeOf(emp, EmployeeWithMethodMissing.prototype);
  return emp;
 }
EmployeeWithMethodMissing.prototype = new Employee();
EmployeeWithMethodMissing.prototype.constructor = EmployeeWithMethodMissing;

And I define a function that will receive a constructor function and wrap its prototype in a proxy that adds the method missing ability to it

//manageMissingItem: function that will be called when an access to a missing property takes place
function addMethodMissingCapabilityToClass(classConstructor, manageMissingItem){
 let _proto = classConstructor.prototype;
 classConstructor.prototype = new Proxy(_proto, {
  get: function(target, key, receiver){
   //console.log("get trap invoked");
   
   if (key in target){
    return target[key];
   }
   else{
    //the problem here is that I can not know if they were asking for a method of for a data field
    //so this makes sense for a missing method, but for missing properties it does not
    return manageMissingItem(target, key);
   }
  }
 });
}

The function above receives as second parameter a function where we will define specific behaviours for when a missing method call happens. I use it below to enable synomymous (alias) to a method. I consider calls to the missing methos "tell" or "speak" as if they were calls to "say"

addMethodMissingCapabilityToClass(EmployeeWithMethodMissing, 
  //manageMissingItem function
  function(target, key){
   if (key === "tell" || key === "speak"){
    console.log(`method missing, but ${key} is synonymous with "say"`);
    return function(...args){
     console.log("calling the returned function with " + this.name);
     return this.say(...args);
    };
   }
   else{
    return undefined;
   }
  }
 );
 
 let e1 = new  EmployeeWithMethodMissing("Laurent");

 console.log(e1.doWork("task1", "task2"));
 console.log(e1.say("Hi"));
 console.log(e1.tell("Hi Again"));
 

I've put it all in a gist

This technique works fine when you have a usage sample like the above, you have a restricted set of possible names of the missing methods. If you just want to trap any missing method invokation you have a problem. In javascript method invokation is done in 2 steps. First the function for that method is retrieved (we get it) and then it's invoked (with the corresponding "this" and parameters). This means that in our get trap we can not know if what is being retrieved is a function or a data field. We can not make the distinction that we make in groovy between methodMissing and propertyMissing. If we return a function for just any "missing retrieval", we'll have a problem for those cases where what they were expecting to get were data. The consumer would be expecting for example a string (or undefined) and we are returning a function that will not get invoked, as he was just accessing data only the retrieval happens, but not the invokation.

Trick: return a function with a "missingMethodReturn" property, so we can dosomething like: let data = p.dataField; data = data.missingMethodReturn ? undefined : data; -->

ES6 and Super

Exploring ES6 is an amazing book. I've been going through some of its chapters randomly and at different levels of depth. It lately caught my attention that in ES6 the syntax for defining methods in one class can be also used in object literals. This means that you can write this:

let user = {
	sayHi: function(st){
	......
	}
};

or this:

let user = {
	sayHi(st){
	......
	}
};

They are almost the same, but not exactly. The first point is to realize that in ES6 we have different kinds of callable entities, though all of them are functions. Reading this chapter these callables are instances of function, but on creation (depending on whether it's a method, an arrow function...) they will get different internal data and methods ([[Construct]], [[HomeObject]]... We could say that each particular callable that we create in our code (via function, arrow, method definition) are instances of different function types.

For method declarations, we can read in this other chapter:

You can’t move a method that uses super: Such a method has the internal slot [[HomeObject]] that ties it to the object it was created in. If you move it via an assignment, it will continue to refer to the superproperties of the original object. In future ECMAScript versions, there may be a way to transfer such a method, too.

I've done a small test to verify that I had got it right:

let stringManagerABC = {
		process(st){
		st = st + " [ProcessingABC applied]";
		return st;		
	}
};

//a normal case, we can say that stringManagerDEF -> stringManagerABC 
let stringManagerDEF = {
	process(st){
		st = super.process(st) + " [ProcessingDEF applied]";
		return st;		
	}
};

Object.setPrototypeOf(stringManagerDEF, stringManagerABC); 
//
console.log(stringManagerDEF.validate("text"));

console.log("------------------------------");

let stringManager123 = {
	process(st){
		st = st + " [Processing123 applied]";
		return st;		
	}
};

//a rather particular case, stringManagerMixed -> stringManager123, but for the process method we are directly giving it the one from stringManagerDEF 
let stringManagerMixed = {
};


Object.setPrototypeOf(stringManagerMixed, stringManager123); 

stringManagerMixed.process = stringManagerDEF.process;

console.log(stringManagerMixed.process("text"));
//text [ProcessingABC applied] [ProcessingDEF applied]
//Not good, it's calling the method in the original parent rather than in the real parent

My understanding from some additional reading is that the [[HomeObject]] field of one method points to the object where the function has been attached at creation time (MyClass.prototype when defined in a class or the "this" at the definition time when in an object literal), so it's static. Finding a generic way to obtain [[HomeObject]] in a dynamic way does not seem simple. One could think of using "this", hasOwnProperty and getPrototypeOf, but that would only work if the inheritance chain has only 2 levels. With more levels we would be going down again in the prototype chain. Of course we could forget about this [[HomeObject]] thing and directly do the super calls by means of MyParentClass.prototype.method. That is not good either, for this same case of moving a method to another object it does not apply, and it would fail in cases like the mixins that we saw last week (you are dynamically creating subclasses).
For the especific case of the sample above, we could use something like the below, but it does not extend to other situations:

let stringManagerABC = {
	validate: function(st){
		st = st + " [ValidationABC applied]";
		return st;		
	}
};

//a normal case, we can say that stringManagerDEF -> stringManagerABC 
let stringManagerDEF = {
	validate: function(st){
		let _proto = Object.getPrototypeOf(this);
		if (_proto.validate){
			st = _proto.validate(st);
		}
		//I can not use super in a method declared via function
		//st = super.validate(st) + " [ValidationDEF applied]";
		return st + " [ValidationDEF applied]";		
	}
};

Object.setPrototypeOf(stringManagerDEF, stringManagerABC); 
console.log(stringManagerDEF.validate("text"));

console.log("------------------------------");

let stringManager123 = {
	validate: function(st){
		st = st + " [Validation123 applied]";
		return st;		
	}
};

//a rather particular case, stringManagerMixed -> stringManager123, but for the process method we are directly giving it the one from stringManagerDEF 
let stringManagerMixed = {
};


Object.setPrototypeOf(stringManagerMixed, stringManager123); 

stringManagerMixed.validate = stringManagerDEF.validate;

console.log(stringManagerMixed.validate("text"));
//text [Validation123 applied] [ValidationDEF applied]
//so this is good, I'm calling to the method in my real parent

Typed Serialization in Javascript

I had written some time ago about "typed serialization" in C# and Perl. What I mean is serializing an object with information about its type, and using that information later on to deserialize it into an instance of the correct type, rather than having that type "hardcoded" in code. I'll describe here one technique to achieve this in modern javascript.

The builtin JSON.stringify and JSON.parse are more than enough for my data serialization needs. Problem is, what about behaviour? JSON.parse will just create a plain object and add data to it, but we want our methods back! Assuming that the methods for your object are in its internal prototype [[Prototype]] (or further up in the prototype chain), and not directly attacched to the object itself, you need to set the [[Prototype]] of the new object accordingly. You can use for that Object.create or the more recent Object.setPrototypeOf.

So let's follow the whole procedure

First we have to serialize our data along with the type information. We'll just wrap our object in another object with that info, like this

 function serialize(obj){
  let aux = {
   typeName: obj.constructor.name,
   data: obj
  };
  return JSON.stringify(aux);
 }

When deserializing we'll have a string with the name of the "type" (the name of the constructor function for our object). To obtain the real function we can use the magic of eval:

function getFunctionFromStringName(functionNameSt){
 eval("var func = " + functionNameSt + ";");
 return func;
}

Once we have the function object, we can assign its prototype to our object, either this way:

//this does not work, Object.create takes a map of property descriptors
  //return Object.create(constructorFunc.prototype, aux.data);
  var obj = Object.create(constructorFunc.prototype);
  Object.assign(obj, aux.data);

Notice the comment. We can not just use the object with the data just deserialized because Object.create expects a bunch of property descriptors rather than simple data.

or this way:

 Object.setPrototypeOf(aux.data, constructorFunc.prototype);

I've put the code in a TypedSerializer class in this gist along with some test code.

Is it a Proxy

ES6 proxies try to be so transparent that they don't offer a way to know if one object is proxied or not. Proxies work in a way that applying the instanceof operator or accessing directly to the constructor property of a Proxy will make you think that it's the original object rather than an Proxy. I mean:

.

class Person{

}
var p1 = new Person();
var proxiedP1 = new Proxy(p1, {/* handler object here */};

console.log("proxiedP1 instanceof Proxy: " + (proxiedP1 instanceof Proxy)); //false
console.log("proxiedP1 instanceof Person: " + (proxiedP1 instanceof Person)); //true
console.log("proxiedP1.constructor: " + (proxiedP1.constructor.name)); //Person

So, what if for some reason you want to know if an object is a proxy or not? And what if you want to obtain the proxied object from your proxy? The simple solution I've come up with is including this functionality in your "get" trap. Write your get trap so that if you ask for a property like for example "_isProxy" or "_proxyTarget" they return the correct value. I mean, something like this.

proxyHandler = {
 get: function(target, propKey, receiver){
  switch (propKey){
    case "_isProxy":
     return true;
     break;
    case "_proxyTarget":
     return target;
     break;
    default:
     //your normal trap code here, for example
     console.log("intercepting...");
     return Reflect.get(target, propKey);
     break;
   }
  
  return Reflect.get(target, propKey);
 }

You should also modify your set trap to prevent _isProxy and _proxyTarget from being set. You can generalize the code to an extendProxyHandler function, like this:

function extendProxyHandler(handler){
 let originalGetTrap = handler.get;
 handler.get = function(target, propKey, receiver){
  switch (propKey){
   case "_isProxy":
    return true;
    break;
   case "_proxyTarget":
    return target;
    break;
   default:
    if (typeof handler.get === "function"){
     return originalGetTrap.call(this, target, propKey, receiver);
    }
    else{
     return Reflect.get(target, propKey);
    }
    break;
  }
 };
 
 let originalSetTrap = handler.set;
 handler.set = function(target, propKey, value, receiver){
  switch (propKey){
   case "_isProxy":
    break;
   case "_proxyTarget":
    break;
   default:
    if (typeof handler.set === "function"){
     return originalSetTrap.call(this, target, propKey, value, receiver);
    }
    else{
     return Reflect.set(target, propKey, value);
    }
    break;
  }
 };
}

I've put this code along with a sample here.

I'll also mention something that is a bit confusing. In the different proxy traps, "this" refers to the proxy. In the get and set traps we also have a "receiver" argument. This receiver is also a proxy, but somehow not the same one!? Let's see:

get: function(target, propKey, receiver){
  console.log("receiver inherits from Proxy: " + (target instanceof Proxy)); //true
  console.log("this inherits from Proxy: " + (this instanceof Proxy)); //true
  console.log("this === receiver: " + (this == receiver)); //false
  //log the method calls
  if (typeof target[propKey] === "function"){
   console.log("intercepting call to method: " + propKey ); 
  }

  return Reflect.get(target, propKey);
 }

AsyncEnumerable

This is a topic that has got me confused a few times, and now that I have seen a reference to something similar for a future ES version, I thought of writing a short reference here.

Let's start by a necessary clarification. When we talk about enumerating/iterating/looping in an asynchronous way, there are 2 quite different things:

• Obtaining the item is not time costly and asynchronous, what is asynchronous is treating the item. This used to be the most common case for me [1] 2. It's what I've usually called async-loops. You would have a list of items and an asynchronous function to run on each of them, and you will pass as callback a function to continue with the iteration. I've written about it a few times. With the advent of async the code is now pretty simple, as the compiler takes care of all the heavy lifting. We now can write code like this (in C#):

  foreach (var item in myEnumerable)
  {
  await treatItemAsynchronously(item);
  }
  

• The other case is when obtaining the iteration item is time costly and hence implemented asynchronously. Thinking in terms of C# and IEnumerable/IEnumerator, that would mean having a sort of async MoveNext. Then, the treatment of the item could also be asynchronous, so we would have case 1 and case 2 together.

This post is focusing on the second case. It would be nice to be able to write something like this (which is just "fiction syntax":

foreach await (var item in myAsyncEnumerable){}

I've read somewhere of awaiting for a method returning a Task<IEnumerable<T>>. That makes no sense. What we could do is to return an IEnumerable<Task<T>> and use it this way:

class FilesRetriever
{
public IEnumerable<Task<String>>> GetFiles(){...}
...
}

var filesRetriever = new FilesRetriever(new List<string>(){"file1", "file2"});
			foreach (Task<string> fileTask in filesRetriever.GetFiles())
			{
				var fil = await fileTask;
				Console.WriteLine(fil);
			}

That is not so bad, but there is a problem. It works fine for cases where the the stop condition of the Enumerator (MoveNext returning false) is known beforehand, for example:

		private string GetFile(string path)
		{
			Thread.Sleep(1000);
			return "[[[" + path.ToUpper() + "]]]";
		}
		
		
		public IEnumerable<Task<String>> GetFiles()
		{
			foreach (var path in this.paths)
			{
				yield return Task.Run(() => {
				                      	return this.GetFile(path);
				                      });
			}
		}

But if that stop condition is only known depending on the iteration item (stop when the last retrieved file is empty for example), this approach would not be valid.

We could think then of some interface like this:

	public interface IAsyncEnumerable
	{
		async Task<bool> MoveNext();
		
		async Task<T> GetCurrent();
	}

that could be combined with a new foreach async loop construct. The loop would get suspended and the execution flow of the current thread would continue outside this function. Then once the Task.Result of that MoveNext is available another thread would continue (the sort of ContinueWith continuation) with GetCurrent, its treatment and the next iteration of the loop. This feature should come with the possibility of doing yield return await.... I assume combining the compiler magic used for yield and await will not be easy.

I've read that there are some requests for something similar

, and one guy implemented a pretty smart alternative back 5 years in time

In ES land, they got the async/await a bit later, but they are striding to get this async iterators thing in the short term. You can read about the proposal here

Blocks and Closures

One of the less exciting features added to ES6 are blocks. You can put sections of code between brackets anywhere in your code and the variables declared there with let will be local to that section. I think Perl has something similar, but honestly I don't see much use to it.
Reading the section From IIFEs to blocks in this nice write up has made me see that in the end they can be useful. The sample there is not complete, so I'll drop one here. We use IIFEs many times to create closures, so with blocks we can move from this:

 var printAndCount = function(){
  var counter = 0;
  return function(){
   console.log("execution: " + counter++);
  }
 }();
        printAndCount();

to this

 {
  let counter = 0;
  var printAndCount = function(){
   console.log("execution: " + counter++);
  }
 }
        printAndCount();

The latter is shorter, but the former has much more freak appeal :-)

Reflect.get

The other day when checking the Reflect API in ES6 I found something that seemed a bit strange to me, the receiver parameter that you can pass to Reflect.get(target, propertyKey[, receiver]) . The explanation says:

The value of "this" provided for the call to target if a getter is encountered.

Notice also that when you do a Reflect.get of a "getter" (accessor descriptor), the getter itself will be executed rather than returning you the descriptor.

So if you don't pass a "receiver" the "this" passed to the getter will be the "target", else the "receiver". The logic behaviour for me is the former, that "target" is used as "this", why would I want to pass a different object? Well, after some thinking I realised this is useful for proxies and what I posted about some time ago, using the proxy for internal calls vs using the proxied object. So if you are proxying the access to a getter and then you want that the actions in that getter also go through the proxy, you'll pass the proxy as "receiver". One first thought was that you could end up with some kind of recursion, but it's not like that. Reflect.get(target, propertyKey, receiver) will do a target.propertyKey to get the getter, and then invoke the getter with "receiver" as "this", which is quite different from doing a receiver.propertyKey, that with a proxy would cause recursion. If your getter is calling another getter and so on, in the end one of those getters will be just calling a data descriptor, so the proxying will end.

With all this, I've put a sample with 3 ways to proxy your method/property access. One that will not go through the proxy for internal calls (neiter method nor accessor descriptors), another that will go through the proxy for internal cases for both of them, and finally one that will do it for methods but not for accessors. You can check the code here.

A reminder regarding method calls. Method calls in JavaScript involve 2 actions, getting the function (so if proxying the get trap gets called) and then doing a call to the returned function passing as "this" the object on which you did the "get" (so if you are using a proxy, the proxy will be passed as "this" to the function, this is important for cases 2 and 3 in my sample)

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

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.

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

Interpreters and JITs

The other day I came across this interesting article about the improvements to the Android runtime. Summarizing, it will start to run an application via the interpreter. Then some parts will be JITted, injecting some profiling code, so that when the machine is idle and charging the hot sections of the code will be recompiled. This recompilation can be applied multiple times, and I think the compiled code is saved, not just kept in memory, so further executions already benefit from this.

Years ago I would think of a world split between Interpreters and JITs. It was reading about the HotSpot JVM when I found that both worlds could be mixed. You start by interpreting the code so that you don't have any initial delay because of compilation, and when it's detected that a method is run very often the JIT compiles it. The astonishing feature provided by the HotSpot JVM is that once a method has been compiled it can be further optimized based on runtime information and "hot swapped". Another interesting feature that I have just learnt is that it can also use OSR (on stack replacement). This means that a method that is being run only once, but for a long while (a big loop) will be detected as a Hot Spot and replaced even when it is running!!! Another cool feature is that as in some cases optimizations can have taken wrong decisions, a method can be replaced by a deoptimized version. You'll find this paragraph interesting:

Remember how HotSpot works. It starts by running your program with an interpreter. When it discovers that some method is "hot" -- that is, executed a lot, either because it is called a lot or because it contains loops that loop a lot -- it sends that method off to be compiled. After that one of two things will happen, either the next time the method is called the compiled version will be invoked (instead of the interpreted version) or the currently long running loop will be replaced, while still running, with the compiled method. The latter is known as "on stack replacement", or OSR.

The .Net runtime does not use an interpreter, just a JIT (and also de AOT compilation via ngen). I could be wrong, but this gives you the impression that it's less advanced than the JVM HotSpot. In .Net 4.6 a new, more performant, JIT (ryujit) is used. From what I've read it's a traditional JIT, neither interpretation nor hot swapping has been added to the mix. Bearing in mind that Ryujit has been on the works for quite a few years and that Microsoft has put a lot of effort on it, I assume they consider that hot swapping is not necessary for huge performance gains.

Reading about all this has woken up my interest on how mondern javascript engines work (Interpreter, JIT, both...).

• V8: (chrome, standard node.js) Rather than an interpreter and a JIT, it includes a fast, not optimized JIT to start with, and then hot methods are compiled via a slower, optimized JIT. Copy pasted from somewhere on the net:

  V8 never interprets, it always compiles. The first compiler is a very fast, very slim compiler that starts up very quick. The code it produces isn't very fast, though. This compiler also injects profiling code into the code it generates. The other compiler is slower and uses more memory, but produces much faster code, and it can use the profiling information collected by running the code compiled by the first compiler.

• Mozilla Spider Monkey: Mozilla's runtime has quite evolved over the years. It started as an interpreter, then they added a particular case of JIT, a tracing JIT (sequences of code are compiled rather than whole methods), and then they replaced it with a conventional per-method JIT (along with the interpreter).
• Microsoft's ChakraCore: From this overview it seems pretty advanced. It uses an interpreter for fast start-up and 2 multithreaded JITs, a fast one and an optimized one. It seems that apart from JITting methods it can also JIT specific loops. Of course the compiled code can be hot-swapped.

If you want to read more about Interpreters and JITs, this makes a good reading.

ES6 proxies part II

I already wrote about ES6 proxies in the past.. Reading this post by Dr Rauschmayer I've realised of an interesting and subtle difference depending on how we create our proxy for method interception.

In "classic" languages (C#, Java...) there are 2 strategies used by the different Proxy creation libraries. One is to use composition (the proxy class will reference the target class), and the other one is to use inheritance (the proxy class inherits from the target class). Based on the "favor composition over inheritance" principle most libraries tend to use composition. There's an interesting difference in the results of both approaches.

When using composition, if the initial method calls into another method in the object, this second call will not go through the proxy. It's normal, the proxy intercepts the first call, does its stuff, and then invokes the method through the target object. Once you are in the invokation done through the target object, the proxy has no way to intercept any ensuing code.
On the other side, when using inheritance, any secondary call goes also through the Proxy, cause indeed there is not this separation between target and proxy, your proxy is the target.

ES6 proxies are based on composition, as you have a target object and you create a proxy that points to it and intercepts actions on it. The big difference is how methods are called. A method in javascript is a property of the object, and calling a method entails 2 steps: getting it, and then invoking it. As explained in the article, ES6 proxies give you 2 traps for method calls, the get trap and the apply trap. When you use the get trap you return a function that will be later on invoked. In this returned function you put the "decorating" code, and the call to the original method. Here comes the cool part, in this function you have both the target object and the proxy (and the name of the property being intercepted), so you can invoke the property (method) either via the target (so it would be like in the composition case, no more interception happens):

//other method calls done from the first intercepted method are NOT intercepted
var entryCallProxied = new Proxy(cat, {
 //target is the object being proxied, receiver is the proxy
 get: function(target, propKey, receiver){
  //I only want to intercept method calls, not property access
  var propValue = target[propKey];
  if (typeof propValue != "function"){
   return propValue;
  }
  else{
   return function(){
    console.log("intercepting call to " + propKey + " in cat " + target.name);
    //target is the object being proxied
    return propValue.apply(target, arguments);
   }
  }
 }
});

or via the proxy itself (either using "this" or "receiver" as both point to the proxy). In this case the interception continues for other method calls performed from this returned function

//other method calls done from the first intercepted method are ALSO intercepted
var allCallsProxied = new Proxy(cat, {
 get: function(target, propKey, receiver){
  //I only want to intercept method calls, not property access
  var propValue = target[propKey];
  if (typeof propValue != "function"){
   return propValue;
  }
  else{
   return function(){
    console.log("intercepting call to " + propKey + " in cat " + target.name);
    //"this" points to the proxy, is like using the "receiver" that the proxy has captured
    return propValue.apply(this, arguments);
   }
  }
 }
});

Given the cat object below, you can see the difference between using one or another type of proxy. In the first case the call from method1 to method2 is not intercepted, while in the second case it is:

var cat = {
 name: "Kitty",
 method1: function(msg){
  console.log("cat: " + this.name + ", method1 invoked with msg: " + msg);
  this.method2(msg);
 },
 
 method2: function(msg){
  console.log("cat: " + this.name + ", method2 invoked with msg: " + msg);
 }
};

entryCallProxied.method1("Francois");

//Output:
// ------------------------------
// intercepting call to method1 in cat Kitty
// cat: Kitty, method1 invoked with msg: Francois
// cat: Kitty, method2 invoked with msg: Francois
// ------------------------------

allCallsProxied.method1("Francois");

//Output:
------------------------------
// intercepting call to method1 in cat Kitty
// cat: Kitty, method1 invoked with msg: Francois
// intercepting call to method2 in cat Kitty
// cat: Kitty, method2 invoked with msg: Francois

At the time of this writing you can run the above code in Firefox. Oddly enought, it does not work in node.js, even if we pass the --harmony_proxies flag. You can get the whole code here.