Wednesday, 18 November 2015

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.

Saturday, 14 November 2015

Je Suis Humain

Je suis Charlie. Je suis Humain. Je suis choqué. Je suis tellement en colère. J'ai mal à la tête et à l'ame. Je me sens plein de haine, de tristesse... Je ne sai pas quoi dire, mais je vais essayer de l'écrire ici.

I am Charlie. I am a Human Being. I'm shocked. I'm so angry. My head and my soul hurt. I'm filled with hate and sadness. I don't know what to say, but I'll try to write it down here.

Last night I was going to bed after doing some hobbyist programming when I read the shocking news, the terror attacks in Paris. I was so shocked, angry and in pain. It took me time to fall asleep. This morning I ran to my laptop to read the news as soon as I woke up, but indeed I don't know why. I mean, I know enough. Some monsters blinded by a sickening perversion of the Muslim faith decided to kill as many innocents as they could. That's all what matters. In the next days we'll read about how they got radicalised, if they came from a Muslim family or they had converted. If their ancestors had been born here or there, or maybe these beasts had just crossed the border. We'll probably read that some of them had grown up in a quartier sensible, and in such case maybe some idiot will tell us how the French society had marginalized them... Maybe some other idiot (considering himself a leftist) will say that fundamentalist Islam exists because of capitalism an inequality. Bullshit, I don't care (and I don't buy it). Radical Islam exists mainly because Saudi Arabia, Qatar and Kuwait want it to exist, that's why they fund it with millions of petrodollars.

Right now all what matters to me is that they are bloodthirsty beasts that hate anyone that does not fit into their perverted vision of the world. They hate me, they hate you, they hate us, they are our sworn enemies and as such they must be treated. Today, more than ever, we are at war, a very difficult war, but in the moral sense it's a really simple one. Usually there are millions of geopolitical factors to account for when thinking about this kind of conflicts (how a past of colonisation, exploitation or previous wars project into the present...) but this case is pretty simple. This is just a war of Good vs Evil, Humanity vs Horror. It's like the war against fascist regimes in the last century, they are just scum that must be destroyed, for good and forever.

I've been seriously touched by these events. Previous terror attacks in New York, Madrid or London seemed very far to me (even when Madrid is geographically slightly closer to Xixon than Paris is to Toulouse). I don't have an emotional connection with those cities (well, I have it now with London, but in 2005 I had been there just once), but I have a strong connection with Paris. In part it's because I've been there quite a few times (and I think in all those occasions I've been around the area where the slaughter has been perpetrated). In part it's because it's the most beautiful city in the world. And in part it is because as it happens with other big French urban areas (Toulouse is a great example), it represents for me the biggest example of how people of different cultures, "races", ethnicities and religions can live together and share a present and a future (yes, for sure it's not perfect and there are problems, but the overall result so far is beautiful and inspiring). So an attack like this is not an attack to a city or a country, it's an attack to the whole of humanity and our shared existence.

Of course the French government has hurried up to state that serious measures will be taken, but which measures? Which real measures were taken after the Charlie Hebdo tragedy? Ah, yes, they put some troops on the streets, watching large train and Metro stations, synagogues... it's quite visible, but it's nothing. I'm not aware of the state watching seriously what is said in mosques and deporting radical clerics. I'm not aware of massive operations against salafist scum, I'm not aware of new policies of assimilation being put in place and replacing the dreadful "communitarism". When is this kind of measures going to be carried out???

The biggst measure that the French government seems to have launched is taking part in the air strikes against Daesh in Syria. Of course I support these actions, but it's not enough and furthermore it's pretty hypocritical. Basically the French government is trying to kill yihadist of French origin that are "fighting" (i.e.raping and enslaving women, torturing and murdering civilians...) in Syria. That's good, for sure, but why the same policy is not applied when they return to France? Yes, sure, this is the Politically Incorrect part of this post. I'm saying that when yihadist return to France they should be executed. They return here after having committed crimes against Humanity (I don't care how many women they have raped or how many people they have killed, if they went there it's because they wanted to do that), and come back with the intent of committing crimes and doing proselytism here. Honestly, and I'm not overdoing, this is right what I think, I'd like them to be shot on the spot as soon as they set foot in Europe. No detention, no trial, just shoot them dead on the spot as they get off the plane. You can call it revenge and brutality, I call it justice.

Thursday, 12 November 2015

Typed Serialization in Perl

After writing this post about deserialization of a type known at runtime, I remembered how out of the box it is achieving the same in perl.

If you've ever written some perl code you'll probably know about Data::Dumper and eval. So well, basically that's all you need for serializing an object and then deserializing it back without having to pass the type as parameter or anything of the sorts. Let's see.

When Dumper serializes a type, it will write the data in the object (your blessed reference or whatever) to a "perl code string", and furthermore, it will wrap it in a call to bless, passing it the type of the object!. I mean:

$VAR1 = bless( {
                 'places' => {
                               'Asturies' => 'Uvieu',
                               'France' => 'Toulouse',
                               'Germany' => 'Berlin'
                             },
                 'name' => 'Francois',
                 'lastName' => undef,
                 'city' => bless( {
                                    'name' => 'Paris'
                                  }, 'City' )
               }, 'Person' );

So we have there perfectly valid code to create a perl object of the right type with the right data. Obviously to dinamically run a string of perl code in our script all we need is calling the almighty eval. Well, just one minor quirk. We have to get rid of the $VAR1 = assignment. Oddly enough perl does not have replace function out of the box to do something like replace(mySerializedObject, '$VAR1 = ', ''), so you either use a regex, or substr

I've put the few lines of code needed for this serialization/deserialization into a class, in case one day I need to change the serialization strategy.

package TypedSerializer;

use strict;
#Data::Dumper::Dump stringifies the content of the object and wraps it in a call to bless with the corresponding type, 
#the main problem is that it adds this assignment " $VAR1 = bless(" ,
#if we pass this string directly to eval, it will fail because of that "$VAR1 = ", so we just need to remove "$VAR1 = " from the string
#so we either use Terse to directly prevent it from going to the string, or we just remove it with substr or a regex

use Data::Dumper;

sub New{
 my ($class) = @_;           
    my $self = {
   };               
   return bless $self, $class;   
}

sub Serialize{
 my ($self, $item) = @_;
 my $str = Dumper($item);
 return substr($str, length('$VAR1 = '));
}

#bear in mind that when the object is deserialized, the "constructor", New, is not called
sub Deserialize{
 my ($self, $str) = @_;
 return eval $str;
}
1;

I've put it up in a gist along with some testing code here

Sunday, 8 November 2015

Top vs Rownum

I guess talking about Sql queries these days, when Non Relational DBs are all the rage, is quite "uncool", but anyway...

For someone that has mainly worked with SqlServer, that fact that Oracle misses the TOP clause is quite shocking. You have to resort to using the ROWNUM pseudocolumn.

So a query like this:

SELECT TOP 10 * FROM cities

has to be written like this for Oracle:

SELECT * FROM cities WHERE ROWNUM <= 10;

It's odd, as I would say almost any other RDBMS out there implements TOP, but well, it's not a big deal. However, there is a huge difference when combined with ORDER By. If you rewrite this query:

SELECT TOP 10 * FROM cities ORDER BY population

like this:

SELECT * FROM cities WHERE ROWNUM <= 10 ORDER By population

You'll have a problem. In the first query the TOP clause to limit the number of results is executed after the ORDER BY, but in the second query, the WHERE ROWNUM condition is executed before the ORDER BY. This means that you will get whatever first 10 rows you have in your table, and then you'll order only those restricted rows, so obviously that is not what we want.

Hopefully the solution is pretty simple. In order to execute first the ORDER BY and then the filtering, you can use a composed query like this:

SELECT * FROM (
SELECT * FROM cities ORDER By population
)
WHERE ROWNUM <= 10

I came to this simple solution on my own, and doing some search to see if there is another better option, it seems like it's the common solution.

Thursday, 5 November 2015

.Net Attributes

I've never been too keen of .Net attributes, I guess because I've always had rather present its big limitation, they are a static, compile time feature, you can not add, delete or modify an attribute for a class, method or property at run time. In part as a consequence of this, they apply at the Type level, not at the instance level, so if you declare a class as [Serializable], all its instances will be Serializable, and you won't be allowed to remove this Serializable attribute.

I think it's common to talk about Attributes just in terms of metadata (notice that when they are applied to classes they are the perfect replacement for the Marker Interfaces. Attributes are more than metadata though, as they have methods they can have behaviour.

Of course Attributes are still pretty useful, but you have to be careful to use them only in situations when these metadata or behaviour are not going to change at runtime, if not, you'll have to keep this information in normal objects that you initialize based on configuration values and that you can change normally later on.

The behaviour for the Java counterpart, annotations, is basically the same as far as I know. On the other side, JavaScript does not have "official" support for Attributes/Annotations (you'll see some libraries that implement them based on comments). But indeed, JavaScript supports dynamic attributes for "classes" and "methods" (I'm talking about pre ES6, that's why I use the quotes). In the end "classes", "methods" and normal functions just come down to functions, functions are objects, and objects can just be expanded with new properties whenever you want. So you can designate your "class" as serializable, or your method/function as "cacheable" just like this:

function Person(){
...
}
Person.serializable = true;

var p1 = new Person();
if (p1.serializable){

}

function algorithm1(){
}

function algorithm2(){
}

algorithm1.fast = false;
algorithm2.fast = true;

if (timeConstrains == true){
algorithm2();
}
else{
algorithm1();
}

Back to .Net attributes, I had never thought about how attributes are stored. I mean, yes an Attribute is a class, but what I wonder is how is stored that one class, method or property is decorated by certain attribute having certain parameters? Everything is stored in the Assembly metadata. You can read here a pretty good explanation.

Going for precision here, all the [attributes] used in an assembly are gathered together by the compiler and written to the metadata of the assembly. Two tables in the metadata play are role.

The first one is the CustomAttribute table, it contains a list of every single attribute. The list entry has an index to the original declaration that had the attribute (1), a reference to the constructor for the attribute type (2) and an index for the value that's used to construct the attribute object at runtime (3).

The second one is the Blob table, the value index (3) in the CustomAttribute table indexes it. It contains the values you used in the attribute declaration. Those values are a string if you used a string or typeof argument, the actual value if you used a value type value argument, an array of those values if you use an array.

Constructing the attribute object at runtime thus involves first finding the entry in the CustomAttribute array by (1). Then locating the constructor for the attribute class by using (2) and jit compiling it if necessary. (3) is used to lookup the entry in the blob table, converting the values in the blob as necessary, like retrieving the Type from the string, creating the array, etcetera. And calling the constructor to create the object.

Organizing it that way has the big advantage that a declaration can have an arbitrary number of attributes and that attributes can be used on many kinds of declarations (assembly, type, method, parameter, field, etc). The disadvantage is that finding them back isn't particularly cheap

Now that we know how they are stored, the next question is, when are attributes created? (I mean, the instances of an Attribute class)
I've been doing some tests, and it goes like this:

  • Creating a class decorated with attributes (the class or its methods or properties) does not create an instance of the attribute.

  • Checking if a class is decorated by an attribute, let's say:
    typeof(Class1).IsDefined(typeof(SimpleAttribute), false);
    does not create an attribute either.

  • Attributes are created for example when code like this is run:
    var attrib2 = typeof(Class1).GetCustomAttributes(typeof(SimpleAttribute), true).FirstOrDefault() as SimpleAttribute;

    You'll use code like that if you need to check some property of an attribute or invoke some of its methods. Think for example in the AuthorizationAttribute and how the framework invokes its Authorize method.