Typing and Binding and why static Type-Checking is a free, automated Test

[Meyer97] contains a neat chapter with definitions that makes it a lot easier to discuss about programming languages when it comes to typing. Here are the basics.

We should agree on the basic construct of object-oriented computation: the feature call or for SmallTalkers “passing a message to an object” and for Java guys and gals “invoking a method”.

The Basic Construct (feature call)

x.f(arg); // [0..n] arguments

(Meyer97, p.610)

Think of a non-trivial class-hierarchy of visual components, a classic example. There is an interface or an deferred (abstract) base class that requires descendants to provide a feature (method) named paint(context). What happens if the compiler does not check that every concrete class has an implementation? We get a type violation at run-time.

Definition: type violation

A run-time type violation (or just type violation for short) occurs in the execution of a call x.f(arg), where x is attached to an object OBJ, if either

(V1) There is no feature corresponding to f and applicable to OBJ.

(V2) There is such a feature, but arg is not an acceptable argument for it.

(Meyer97, p.612)

Object-oriented typing problem

When do we know whether the execution of an object-oriented system may produce a type violation?

(Meyer97, p.612)

In SmallTalk, the compiler does not check if every instance that declare “I’m a VisualComponent” does have an implementation of the method “paint()”. The developer can only verify the expected operation of the system by exercising the code in tests or production or by manually checking all classes.

Definition: statically typed language

An object-oriented language is statically typed if it is equipped with a set of consistency rules, enforceable by compilers, whose observance by a system text guarantees that no execution of the system can cause a type violation.

Doesn’t every organization crave for a look in the future? (Hint: If you are using a certain system called Oracle you know the answer 🙂 ). Using a statically typed language is basically a look into the future for free. You can see if your system is bound to fail at run-time. Giving that away doesn’t seem too smart.

Here are the characteristic properties when it comes to demixing your preferred language type-wise:

Typing and binding

  • Typing question: When do we know for sure that at run-time there will be an operation corresponding to f and applicable to the object attached to x (with the argument arg)?

  • Binding question: Which operation will the call execute?

(Meyer97, p.621)

Given that early detection of errors results in the lowest fixing costs it is desirable to know the answer to the question “when do we know we have a feature?” at “the earliest possible time”, determined by static type checking at compile time.

The answer to “what feature do we use?” should be “the right feature” – determined by dynamic binding at run-time.

Think of type checking a statically typed language text as an automated test you do not have to write because it is build into the system. I like that because it leaves more quality time to write tests that cannot be created by a machine :-)!

[Meyer97]    Meyer, Bertrand: “Object-Oriented Software Construction, Second Edition”, Prentice Hall, 1997.

Advertisements

The Test Tool Tutorial that was not Tested

If you happen to follow the JBoss Arquillian Getting Started tutorial (revision Dec 01, 2012) the first thing you’ll notice when running the example is: It doesn’t work :-). Dependency Injection just fails because of a bug in a dependency (probably ARQ-814):

 <dependency>
            <groupId>org.jboss.arquillian.container</groupId>
            <artifactId>arquillian-weld-ee-embedded-1.1</artifactId>
            <version>1.0.0.CR3</version>
            <scope>test</scope>
  </dependency>

fails, but

 <dependency>
            <groupId>org.jboss.arquillian.container</groupId>
            <artifactId>arquillian-weld-se-embedded-1.1</artifactId>
            <version>1.0.0.CR3</version>
            <scope>test</scope>
 </dependency>

succeeds with injection — note the small difference between se and ee. Obviously nobody took care to run the examples again after updating the text. I was using Java 7 and Maven 3.0.4 by the way.

It’s ironic that the tutorial example of a test tool fails in its core functionality because it’s not properly tested. I would expect an automated test to run the example as part of the Continuous Integration or Delivery process and generate the code examples from those.

Arquillian itself is very useful for some tests, I used it in the past but without the Weld CDI container. But be prepared – there are more, trickier bugs of course ;-).

A little reminder for me on how to quickly setup Jenkins on Ubuntu

Installation (from Jenkins installation guide)

wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins

The package creates the user jenkins. Interesting locations are:

  • Settings (HTTP port!) are at: /etc/default/jenkins
  • Jenkins daemon startup: /etc/init.d/jenkins
  • Log file: /var/log/jenkins/jenkins.log

I prefer a different HTTP port than the 8080 default one, so I am going to change the default settings:

sudo vi /etc/default/jenkins

Find the value HTTP_PORT and change it to a free port (don’t forget to document in your Wiki!), for example 8282. Restart jenkins:

$ sudo service jenkins restart

Future updates are fetched by apt-get like any other package:

sudo apt-get update
sudo apt-get install jenkins

Missing Apple MacBook Keys: How to map the INSERT key in Linux/VirtualBox

The Alt+Insert shortcut is literally the key to the code generation menu in the NetBeans IDE. Using a PC keyboard in office this does not impose a problem but Apple’s MacBook line of notebooks does not have an insert key so development when sitting in a train is awkward.

Instead of changing the key in NetBeans I was looking for a way to map a rarely used key as the Insert key, using the X11 key mapping facility. I chose the circumflex ^, as I cannot remember when I needed it the last time. An alternative may be the to use the shifted key (keycode 50) that is mapped to ° by default.

Here’s a nice description on how to change keys in X11 that helped a lot. First I checked the keycodes using the xev tool which prints X11 event information using a console window:

xev

Then I added a new mapping expression:

 xmodmap -e "keycode 49 = Insert Insert"

I created a custom mapping file,

$ xmodmap -pke > ~/.Xmodmap

that is loaded in ~/.xinitrc:

#!/bin/sh
if [ -f $HOME/.Xmodmap ]; then
  /usr/bin/xmodmap $HOME/.Xmodmap
fi

Currently I am very happy with this solution, as it does not require custom bindings in NetBeans, provides the Insert key in all applications and does not get in the way when using a full-size MF-II keyboard.