Wednesday 30 December 2015

The Fall of Constantinople

The other day, when talking about how islamofascists (salafist scum and so on) are destroying the French society (and the Syrian, Libanese, Egyptian, Tunisian, British, Belgian... societies) I had to listen once again one of those demented comments coming from "the collaborationist left" that always finds a way to justify whatever atrocity perpetrated by perverted, fundamentalist "muslims". This time the argument was based on the horrors of colonialism, so it seems that the bad doings during colonial times justifies that someone that has been living in France (and taking advantage of some parts of the French system: social aids, heath system... and rejecting others: educational system, cultural centers...) during all his life decides to join a sect of sociopaths and spread their sickness by preaching (and using) hate and violence against anyone that does not adhere to their sickening interpretation of the world.

I am fed up with this view where "the old" Europeans should be blamed for everything, and where the "new Europeans", the people from the old colonies that are now a proud an essential part of our societies should consider themselves as "traitors". The past is the past, and of course it needs to be known and used to understand the present, but not to justify everything.

This said, I'm going to enter the game for a few minutes, I'm going to talk about the horrors of colonialism, but another kind of colonialism, the one that "the collaborationist left" seems to forget or to be ignorant of. Europe has suffered different invasions over centuries, let's name some of them:

Regarding the Ottomans it would be interesting to note that their invasion still continues today. Just think about the city currently known as Istambul, its part lying on European soil used to be known as Constantinople, and during the times of Bizantium it was one of the great (or maybe the greatest) European cities. Then the Turks came, invaded, looted and murdered... and they have never been asked to decolonize and return the city to Greece... the big Turkish city is one of the greatest reminders of to what extent Turkey is not our alley, but just the contrary.

There's an imposing and beautiful painting in Toulouse's Augustins Museum by the Orientalist painter Benjamin Constant, The Entry of Mahomet II into Constantinople that gives us an exceptional glimpse into the tragic and painful day when the Ottoman hordes entered the magnificent Byzantine city.

Wednesday 23 December 2015

Structural Typing and Dynamic Languages

The other day I read for the first time about Structural Typing. Nothing particularly revolutionary, but interesting anyway. It tends to be defined as a sort of Compile-time duck-typing for static languages. Scala seems to be the most "mainstream" language implementing this feature.

Duck typing is one of the basis of dynamic languages. You don't consider that an object is suitable for an action depending on a strict contract like its type, but in a much more relaxed "having whatever methods I need" kind of contract. Structural typing allows us to indicate those methods that we require that an object sports. The advantage of this over directly grouping those methods in an interface is that as we are not forcing classes to implement an interface we can apply it to existing classes without modification, the compiler we'll provide the safety by checking that the class really has those methods.

I think being able to define a set of methods that an object needs to have could be a useful addtion to duck typing in dynamic languages. Let me explain:


function doSomething(ob1){
ob1.method1();
//do something more
ob1.method2();
}

In the above case, we could receive an object that has method1, but not method2 (it's a "partial duck" not a "full duck"), so our doSomething function would not fail until it calls to method2. Depending on what this code really does, running it only partially would be useless or even dangerous (so that we could need some sort of rollback)

So it could be interesting to have something like this:


function hasMethods(ob1, methodNames){
//returns boolean
}

function doSomething(ob1){
if (hasMethods(ob1, ["method1", "method2"])){
ob1.method1();
//do something more
ob1.method2();
}
}

Saturday 19 December 2015

YellowKorner

I think YellowKorner is an absolutely amazing place for anyone that is into photography, or just into beauty. I first came across one store of this publisher of Artistic Photography here in Toulouse and I was just delighted by the exquisite pieces of photography that I found there. In a city that sports a pretty good offer of Museums and galleries, YellowKorner ranks at the highest position in my podium of cultural references.

Talking about the art centres of "ma ville", Toulouse features one of the oldest public places in the world dedicated to photography, Le château d’eau. They usually have on display 2 different exhibitions for around 2 months. So far I've been in some of these exhibitions and they were OK, but not particularly interesting. However, this spring I attended to a really good one taking place in the cute, imposing (the exterior is rather reminiscent of Albi's Sainte Cécile) and just revamped Couvent des Jacobins. It was a selection of works in the château d’eau collection, intendend to celebrate its 40th anniversary, and some of the pieces were really remarkable.

Over time, I've come across YellowKorner branches in many other French cities: Paris, Montpellier, Aix en Provence... and today checking their web site I've found that they have shops in many other countres, even in Asia. I really recommend you to take a look at their list of locations, so that next time you visit a city hosting one, you don't miss to pay a visit. The works on sale change enough to make it well worth to pay a visit to a YellowKorner establishment at least once every 2 months.

Thursday 10 December 2015

ES6 Constructors

I've previously said here that I'm not particularly excited about the addition of classes to ES6, though well, as they are mainly syntactic sugar all the magic of Prototype based programming (or OLOO, Objects Linked to Other Objects) remains. Anyway, regardless of our predisposition to it, as they will become mainstream we'll have to end up using them, so I thought it was good to get used to them.

One feature in "classic JavaScript" that I pretty like is that we can decide in our "constructor functions" (those that we designed to be invoked with new) to return a different object, rather than the one that has been passed to it as "this". The main use that I see for it is for having a pool of objects, or an "implicit/transparent" singleton (that is indeed a particular case of an Object Pool). With this in mind I was wondering if ES6 class constructors would allow that. Hopefully yes. It's well explained in this post by Dr Rauschmayer. He calls it "Overriding the result of a constructor". I had not thought that the [Prototype] of a "class" points to the Parent "class", but it makes pretty sense in order to inherit static methods. This diagram shows the whole picture of how objects the class inheritance sugar is translated into the prototypal world.

The whole article is pretty interesting. Reading it I found out that classes are not just compile time sugar, but that their inclusion has indeed modified the way the runtime works, as the creation of the object passed as this to a (constructor) function is done differently:

The instance object is created in different locations in ES6 and ES5:

In ES6, it is created in the base constructor, the last in a chain of constructor calls.
In ES5, it is created in the operand of new, the first in a chain of constructor calls.

ES6 involves many more runtime changes, like the new Internal properties featured by functions: [[ConstructorKind]], [[Construct]] and [[HomeObject]], and as the conclusion of the article states, one main point is that now we have different kinds of functions:

  • On one side we have Constructible functions, that I understand are those that can be called with new (as they have [[Construct]]), these are our "normal" functions and the ones created by a constructor definition.
  • Then we have Arrow functions, which have 2 main features: not being constructable, and capturing the lexical this (so for the latter it's as if you had called Function.bind)
  • And then functions created by method definitions, that are not constructable, use dynamic this and can use super.

Classes in ES6 follow a similar approach to other languages regarding missing constructors. If you don't provide a explicit constructor in your class definition, the compiler will add one. This one for a base class: constructor() {}, and this one for a derived class: constructor(...args) {super(...args);} .

As a JavaScript function can receive a different number of parameters, the idea of function overloading that we have in static languages does not exist, and hence a class can have only one constructor function. As a consequence we don't have the minor "problem" that can happen in static languages if a base class misses a parameterless constructor. It's described here

The article mentions something that is missing in ES6 classes and that even deserved an entry on its own, calling a constructor without new. The importance given to something like this really puzzles me. I've never understood the "effort" taken by some libraries (for example underscore.js) in pre ES6 times to allow you to call a fuction that is going to be used to create objects (what in pre-ES6 times we used to call a "constructor function") both with and without new. I'm referring to code like this:

function Person() {
    if (!(this instanceof Person)) return new Person();
    //normal initialization code here 
    //this.property = val;
  };

The idea that this is in case someone forgets to use new seems senseless to me. You have to know the rules... is as if you try to call a method with "->" rather than with "."... Reading the comments Rauschmayer explains that the use case is this :

The use case is if you want to remain flexible w.r.t. implementing something via a class or via a factory function. For my own code, I wouldn’t mind this kind of minor refactoring. For libraries, this becomes more important.

I assume he refers to having a function that receives as parameter another function that will be used to create one object. Your code does not know if that function is a simple one or a "constructor" one, it will just invoke it without new. The designer of that function wants to allow 2 use cases: the one I have just described, where the caller does not really know what function this is, and the normal one where the caller calls this function with new.

function Person() {
    if (!(this instanceof Person)) return new Person();
    //normal initialization code here 
    //this.property = val;
  };

function test(objectCreatorFunc){
   var o1 = objectCreatorFunc();
}

//normal use:
new Person();

//pass it as a factory to the test method
test(Person);

Well, the idea seems useful, but not having it in the language is pretty simple to circunvent, just do the extra step of creating the factory:

class Person() {
    constructor(){
     //this.property = val;
 }
  };

function test(objectCreatorFunc){
   var o1 = objectCreatorFunc();
}

test(function(){
 return new Person();
});

Searching a bit about other people thoughts on this topic I've found articles like this. The guy is really against the use of "new", saying:

The `new` keyword violates both the substitution principle and the open / closed principle. It’s also destructive because it adds zero value to the language, and it couples all callers to the details of object instantiation.

If you start with a class that requires `new` (all classes in ES6) and you later decide you need to use a factory instead of a class, you can’t make the change without refactoring all callers. Take a look at this example gist.

At first thought the idea of discouraging "new" and just using factories can sound odd, but on second thought it makes sense, cause as he says it causes huge coupling. But giving it another thought, we've already heard about avoiding "new" and using Dependency Injection for that. So yes, the idea of being able to call a function (contructor/factory) with or without new is meaningless, what you need is to inject those objects. Indeed, linking this to the feature that I mentioned at the start that in principle I liked (returning a different object from a contructor), it should not be a class itself that decides that it uses a pool of instances of itself, that's something should be managed externally, by the IoC.

Reading that whole post has been a pretty good thought exercise. He mentions that "super" should be deprecated, as it causes heavy coupling. Well, sure, because as he mentions earlier in the article, "extends", that is, inheritance, causes heavy coupling and should be avoided. Well, this is nothing new, it's just the "favor composition over inheritance" principle. In that sense, reading this answer in StackOverflow about why inheritance is heavily coupled has been a more that welcome reminder of why we should do so.

http://js-bits.blogspot.fr/2010/08/constructors-without-using-new.html ------------- https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3#.g3ynqbd4j http://martinfowler.com/bliki/CallSuper.html Dependency Injection

Sunday 6 December 2015

Hotel Descas

Already in my first incursion to Bordeaux 2 years ago I came across with one impressive building that was not mentioned in the guides that I had been reading, the Hotel Descas or Chateaus Descas. I've had pending a short post about it ever since, so given that today I've passed by it, marvelled again, and taken some fresh pics, it's about time to cross it off my ToDo list.

It's one more sample of that astonishing kind of French building that almost obsesses me, like the Hotels de Ville of Paris and Lyon, the Louvre... but you'll find them everywhere in France. The feature that I appreciate the most are those incredible slate roofs so huge and complex. For sure Chateau Descas is a great example of that kind of roofs, and it also boasts beautiful sculptures and mascarons on its facade. This kind of buildings exist since the French Renaissance, but the so intricate roofs are probably a more baroque element. The facade itself I assume fits into the Beaux Arts style. I'm a pretty ignorant person regarding architecture (I just like it), so probably what I'm saying is rather wrong.

I just leave you with some poor pictures to whet your appetite.

Imposing:

Facade details:

The roofs:

In English:

En français: