dow.ngra.de

One of the main problems brought out when comparing dynamic languages to static ones is lack of proper refactoring support. It is usually implied that dynamic languages are not conceptually refactorable, which speeds up code rotting.

Although there is plenty of evidence that dynamic languages do support refactoring, I’d like to concentrate on the other claim — that statically typed languages are refactorable. Challenging this claim may seem laughable, as there is no lack of refactoring tools for Java or C#. But let’s examine a more advanced language that is touted as Java successor — Scala.

Scala supports structural types, which allow treating classes as records of methods that can subtyped by the presence of appropriate methods. This example was given in the Scala 2.6 release notes:

In this code the type { def getName(): String } refers to any class with the method getName(): String in it. Now what happens if we try to rename the method in the structural type?

1. We can rename all the instances of the getName() methods found in all classes anywhere.
2. We can just rename the method in the structural type and update everything else manually

Both of these approaches are useless. The first one is basically a search and replace done on all code and may rename methods that we never intended to rename (e.g. getName() in the Person class). The second one doesn’t really do anything for us.

The truth of the matter is that structural types miss an inherent scope associated with nominative (i.e. usual) types. Since every method signature in a nominative type originates from a single type, it gives refactoring a natural scope of all the subtypes of the originating type. Without that scope many refactoring techniques are essentially useless.

What is worse is that the presence of structural types also breaks refactoring in usual classes. E.g. if we try renaming getName() in the File type, we are also presented with a decision whether or not we can rename the method in structural type. And if we do rename it, we will break the code that accesses java.io.File the same way. Therefore if we want to refactor working code to working code we can again only rename everything or nothing at all.

Luckily it looks like the main refactorings broken by the structural types is renaming the methods and changing their signature. Unluckily these are the most common refactorings and having a same named method in any of the structural types breaks refactoring also in the usual classes. At the moment this mainly affects Scala and some other functional languages, but if the structural types become more spread it may come to a language near you :)

Interestingly, Cedric Beust brought out that you can refactor structural types as opposed to the duck types. Since I obviously think differently it would be interesting to hear his (and your) comments on the matter. Perhaps I’m missing something obvious?

OK, I think I managed to solve both the primitive and the double slot problem introduced in the previous post. Basically I introduced another parametrized class — InvokeBuilder, which builds method invocations. The example now looks like this:

Of course InvokeBuilder contains methods only for building invocation. The only inconvenience is that you have to specify parameters in reverse order to coincide with the way they are laid out on the stack. However it’s easy to add a bit of sugar for the most common cases.

Now all I have to do is overload the param() method for each primitive as well as make a paramTwoCell(), which consumes two stack slots (for long/double). Seems that only tedious work in implementing each and every instruction remains.

P.S. Thanks to Christian Vest Hansen for his input. It definitely helped me get this (last?) piece of the puzzle in place.

Static v/s dynamic types: I will look now into the pros & cons of static typing. What if it’s not really a technical but more of a psychological matter?

This is not exactly an eye-opener, but static types will create a mind map of the project code with considerably less effort than dynamic types. And as long as that map is not important (the project team is small and code complexity is within reason), dynamic types will outperform the extra kickoff needed to fit your design (or lack of it?) into a static paradigm. But when you have to share your code with someone else (even if its yourself in a while) then the dynamicity requires a discipline that is beyond most people.

BTW the constant refactoring debate does not really refer to static types as such, but rather static nominal types a la Java. E.g. in Scala you have structural static types, which cannot be refactored in any reasonable way. When the type system gets complex with a lot of partial structuring and type inference refactoring is almost just as challenging as with dynamic languages.

I have just attended a great course on JavaScript soft typing by Peter Thiemann. No doubt I’ll write more about it later, but today I want to show how fun and quirky can JavaScript be.

Note that all puzzles are given in succession and every next one includes all the code of the previous ones. Also note that I tested the puzzles in Mozilla Rhino, and can’t be held responsible for how standards non-compliant browsers (read Internet Explorer) will behave.

Puzzle 1

> var obj = {x : 1}

What are the values of

1) obj.y
2) print(obj.y)
3) obj.y.z

[Answer]

1) Value is undefined
2) Prints "undefined"
3) Runtime error
  

Puzzle 2

> var x = "x"
> obj.undefined = "gotcha"

What are the values of

1) obj[x]
2) obj[obj.y]

[Answer]

1) 1
2) "gotcha"
  

Puzzle 3

> var a = 17
> a.x = 42

What are the values of

1) a.x

[Answer]

1) undefined
  

Puzzle 4

> var flag = new Boolean(false);
> result = flag ? true : false;

What are the values of

1) result

[Answer]

1) true
  

Puzzle 5

> function f() {return this.x}

What are the values of

1) f()
2) obj.f = f; obj.f()
3) new f()

[Answer]

1) x
2) 1
3) [object Object]
  

Puzzle 6

> function g1() {
>   u = 2;
>   print(u);
>   var u;
>   u = 3;
>   print(u);
> }
>
> function g2() {
>   u = 4;
>   print(u);
>   eval("var u");
>   u = 5;
>   print(u);
> }
> u = 1;
> g1();
> print(u);
> g2();
> print(u);

1) What values are printed out?

[Answer]

1) 2, 3, 1, 4, 5, 4