Rewriting Java in Scala & Making Code Lovely 5 – Structural Typing

What is structural typing?

Structural typing is a way of saying that we don’t care about the type of a variable but we do care about the structure of the type of a variable.

Here’s a simple example to explain this further:

def printArea(shape : { def area : Double}) {
    println(shape + " has area " + shape.area)
}

The interesting part of the above function is the type of the argument shape; shape is a structurally typed variable. We can pass any object we want to the printArea function so long as it has a function called area that returns a Double:

case class square(val sideLength : Double) {
  def area = sideLength * sideLength
}
 
printArea(square(5.0))
// square(5.0) has area 25.0
 
case class circle(val radius : Double) {
  def area = scala.math.Pi * radius * radius
}
 
printArea(circle(10.0))
// circle(10.0) has area 314.1592653589793

We can go as far as you want with specifying structural types:

def pointlessFunction(thing : { 
    def areaWithMultiplier(multiplier : Double) : Double
    def length : Double}) = {
  // ...
}

The above function takes any type that has two functions:

  • areaWithMultiplier that has one argument of type Double and returns a Double
  • length that returns a double

But, the above example is ugly. Type aliases to the rescue:

type t = {
  def areaWithMultiplier(multiplier : Double) : Double
  def length : Double
}
def pointlessFunction(thing : t) = {
  // ...
}

Here we’ve created a type alias t that aliases the complex structural type. We then use that type in the definition of pointlessFunction in the same way we’d use any other type.

What’s the use?

Very Reusable Functions

One of the great uses of structural types is that they allow us to create very reusable functions. For example, we could write a function that sorts a list of shapes according to their size without requiring that the shapes implement a common interface:

type hasArea = { def area : Double }
 
def sortShapes(list : List[hasArea]) : List[hasArea] = {
  list.sortWith(_.area < _.area)
}
 
sortShapes(
  List[hasArea](square(5.0), square(6.0), circle(2.0), circle(3.0))
)
// Result is: List(circle(2.0), square(5.0), circle(3.0), square(6.0))

We could then pass anything we wanted to this function: shapes, countries, building plans, anything with an area function.

This becomes incredibly useful when implementing algorithms. For example, an algorithm that determines how to fit different shapes into a box could be used on any type that implemented the required method.

Legacy Classes

Structural types are also a great way to make legacy types easier to use.

We are given two classes that represent different types of customers: BusinessCustomer, IndividualCustomer. Both of these classes have a method getPhoneNumber. They don’t share a base class. We want to use a library that allows us to call these people from our computer. The typical Java approach might be something like:

public void dial(Object customer) {
  String phoneNumber;  
  if (customer instanceof BusinessCustomer) {
    phoneNumber = ((BusinessCustomer)customer).getPhoneNumber();
  } else if (customer instanceof IndividualCustomer) {
    phoneNumber = ((IndividualCustomer)customer).getPhoneNumber();
  } else {
    throw IllegalArgumentException("Argument isn't a customter " + customer);
  }
  Dialer.dial(phoneNumber);
}

Ugh.

Apart from this being a lot of code for something simple, you won’t be told of errors at compilation time!

Enter structural typing:

def dial(customer : { def getPhoneNumber : String }) = {
  Dialer.dial(customer.getPhoneNumber)
}

Much better. Compile-time safe and far easier to follow.

Duck-Typing

Structural typing is effectively duck typing. Forget littering all your classes with random interfaces IsCloneable, IsSortable, IsComparable, IsJedi… use structural typing and we can say “so long as this argument has a certain property then I’ll use it”.

This gives us some of the benefits of dynamic typing (being able to use whatever we want wherever we want) without losing the benefits of a compiler to make sure we’ve not done something silly.

Under the Covers

Under the covers Scala generates byte-code similar to the following Java:

public void printArea(Object shape) {
    double area = (Double)shape.getClass().getMethod("area").invoke(shape);
    System.out.println("Shape " + shape + " has area " + area);
}

That’s reflection at work. The up-side of this is that we can use our functions from Java code – but without any compile-time type safety. All structural types get compiled down to Object and Scala does the work at run-time to determine if the argument fits the function.

Summary

Structural typing allows us to use arguments according to what properties they have, not what type they are. This can be a very powerful tool and lead to very neat code. It also gives us the benefit of greater compile-time checking when compared against using instanceof in lots of places.

If you want to see a great real-world example of structural typing then take a look at Java to Scala – Smaller Inheritance hierarchies with Structural Typing.

Introducing Gleam

Over the past few months I have been working on a new programming language for the JVM. It’s called Gleam and its purpose is to make view layer programming for web applications easier.

You can read more on the approach taken and the problems it is trying to solve here and here.

I have created a site for Gleam (written using Gleam) and it is located at http://www.gleam-lang.com.

The source for Gleam is on github at http://github.com/gleam. The compiler is written in Scala and is gradually getting completely rewritten now that I’ve firmed up the design (read: I’m not proud of the code itself, just what it does).

So, without any further ado, have a play!

Feedback

I’d love to hear any feedback or questions on this! Please comment, twitter, e-mail me and I’ll get back to you :)

Benefits of Working in a Higher Level for Web Pages

In my previous post I discussed how working in a higher level of semantics than HTML can be beneficial when writing web pages.

To summarise, suppose you write pages like this:

section(name="Contents") {
  The contents go here.

  We use an empty blank line for paragraph spacing.
}
button(link="somelink", label="Click me!")

You can then map these constructs to HTML provided by a designer. I proposed that this is better for everybody.

But, there are more benefits to this beyond what I initially suggested.

Multiple Mappings

CSS was supposed to give us full control over layouts and make it easy to do things like user themes, printer themes and accessibility themes. Unfortunately, CSS hasn’t quite delievered – we’re still heavily restricted by what the HTML is.

By writing your pages at a higher level and mapping them to HTML you can benefit from multiple mappings. Perhaps you want a more accessible version of your page where buttons are just link elements and don’t have any non-meaningful tags around them. Perhaps you want an entirely different layout / structure for people browsing on mobile devices.

Perhaps, just perhaps, you don’t even want to output to HTML all the time. There’s no reason you couldn’t map the above to controls in a Windows form. When we write our web pages at a higher semantic level we give ourselves greater ability to have flexible output.

Improved Testability

When mapping a snippet such as the above you don’t have to map it to HTML. You could map it directly to XML. This simplifies testing as there are definite elements you can check for and any xpaths or regular expressions you use become far simpler.

This is an example of separation of concerns. Your pages are only concerned with high level structure and content. Your mappings are concerned with how a button as actually gets mapped to HTML. You can now test these separately.

You could even use this to drive browser testing. Use the high level structure, as above, to guide your browser. By looking at the high level semantics and understanding the mappings you can reduce some of the fragility that is common in browser testing.

Correctness

You could impose that certain constructs can only be used within certain other constructs. For example, a subsection can only be used in a section. This makes it easier for people to get things right, which leads to better quality pages and an improved user experience.

Your designers can also impose that the correct HTML is output every single time. Again, better quality pages and an improved user experience.

Does this exist yet?

Nearly ;-)

I have written something that implements this style of writing views. However, I haven’t yet got it all packaged up ready for an alpha release. Within the next week or two I’ll be following up with a blog post to share it.

I’m hoping that by writing these posts before the release I can share some of my vision and people understand where I’m going with it.

I’d love to hear any comments on this approach :-)

HTML – Machine code for web pages

Writing web applications using HTML is like writing business logic in machine code.

When you write your web application using HTML directly you lose most of the benefits that the software development world has worked hard for:

  1. No re-use
  2. No compile time safety (type checking, validity of names, valid use of tags, etc…)
  3. Hard to understand code

I’ll quickly explain what I mean by each of these.

No re-use

Most templating languages don’t allow you to re-use HTML snippets. If you want your buttons to be a span of text surrounded by two img blocks (e.g. the left/right ends) then you will have to copy and paste this snippet everywhere you want that style used:

<a href="somelink">
  <div class="button left" />
  <span>Click me!</span>
  <div class="button right" />
</a>

Even worse, as soon as you want to change that style you’re going to be changing a lot of HTML that is largely the same.

Some folks will want to tell me that this could be done with a single a tag and clever use of CSS. Unfortunately, this isn’t always supported by older browsers and it isn’t always easily cross-browser compatible. Sometimes, you just have to write horrors like the above.

Some templating languages allow you to re-use HTML by doing function calls:

<?php button("somelink", "Click me!"); ?>

This isn’t too bad, except it’s done at the cost of #3 – your code loses it’s clarity as you start to switch from HTML to PHP and back again (it’s not just PHP that suffers from this).

No compile time safety

Let’s take a trivial example:

<strong><em>Hello there!</strong></em>

Oops. We’ve just written bad XHTML. Not only is this bad XHTML but some browsers will struggle to make sense of this as HTML as it’s just confusing.

This isn’t the worst of it either. We’re prone to forgetting closing tags, using the wrong tags, using variables that don’t exist… and most of this isn’t found until runtime.

Hard to Understand Code

I’ll go back to my earlier button example:

<a href="somelink">
  <div class="button left" />
  <span>Click me!</span>
  <div class="button right" />
</a>

If you saw this amongst a lot of other HTML you’d have to stop and think about what this HTML is actually doing. Wouldn’t you rather just express yourself and say “I want a button that links to page X with label Y”?

The Root Cause: Working at the Wrong Level

I think that the root cause for these problems is that when we’re writing HTML we’re working at the wrong level. It’s like working with machine code. Instead of thinking:

I want a header here, some text here and a button here”

We’re thinking:

I want a h3 tag here. A div here with a few p blocks in with my text in. Another div here for my button, containing two images and some text… oh, and the hover text! Must not forget the hover text!

And this is very low level thinking – just like when working with machine code.

Bringing in the Semantics

How about we write our page more like the following?

section(name="Contents") {
  The contents go here.

  We use an empty blank line for paragraph spacing.
}
button(link="somelink", label="Click me!")

This could then be compiled and the output could use HTML snippets. HTML snippets carefully crafted by our lovely designers to ensure consistency throughout the app. For example, the button in the above could expand out to the HTML I specified above.

We’re now expressing our front end at the right level. Further, by having the above use HTML snippets provided by designers we maintain the ability for designers to edit HTML carefully and correctly – they then become similar to the machine code wizards who write the compilers :)

Where next?

I’ve been working on implementing something similar to this style of writing views for some time now. Within the next week or two I’ll be following up with a blog post to share it.

Until then, I’d love to hear any comments on this approach.