Category Archives: Hacking

A few of my favorite Vala things: interfaces

In my prior post on Vala’s language features, I discussed enums and how I appreciated Vala’s implementation of them.  I feel that Vala’s enums straddle an interesting line of utility and pragmatism.  It took me a while to learn about their features, partially because documentation has been sparse (but is getting better) and partially because as a C / C++ / Java programmer, I’d had hammered into me a set of expectations about enums that Vala didn’t quite adhere to.  (I had a similar learning curve, for many of the same reasons, about Vala’s lock keyword.)

Learning interface in Vala was a similar experience.  Consider the Java Language Specification’s opening statement about interfaces, which Vala’s interfaces look to be a descendant of:

An interface declaration introduces a new reference type whose members are classes, interfaces, constants and abstract methods. This type has no implementation, but otherwise unrelated classes can implement it by providing implementations for its abstract methods.

Compare to this statement in the C# Programmer’s Guide:

Interfaces consist of methods, properties, events, indexers, or any combination of those four member types. An interface cannot contain constants, fields, operators, instance constructors, destructors, or types. It cannot contain static members. Interfaces members are automatically public, and they cannot include any access modifiers. … The interface itself provides no functionality that a class or struct can inherit in the way that base class functionality can be inherited.

What’s interesting about Java and C# interfaces is what they can’t provide: implementation.  Interfaces are often touted as a sane solution to the problems surrounding multiple inheritance, but it always struck me as odd (and a bit of a blind-spot on the part of their boosters) that interfaces provide no reusable code.  After all, isn’t that the name of the game?  Especially for a technique that’s replacing a form of inheritance, which is all about reusable code?

(I have a pet theory that if one was to study the history of the development of software development technologies — languages, tools, paradigms, all of it — it’s primarily a history of reusable code.  How much money and manpower has been dumped into this holiest of Holy Grails: write once, debug a bit more, reuse a billion times.)

Like enum and lock, Vala offers an interesting interpretation of interface with a couple of surprises.  I’m not sure how much of it is due to the mechanics of GTypeInterface, Vala’s influences from Eiffel, or simply a reflection of Jürg’s vision, but it’s cool all the same.

Let’s start with a simple Vala interface that looks familiar to any Java or C# programmer:

interface Agreeable {
    public abstract bool concur();
}

In-the-know Java programmers will say that the public and abstract keywords are allowed but not required; in C#, they’re simply not allowed.  But in Vala, neither are optional:

interface Agreeable {
    bool concur();
}

produces this compiler output:

error: Non-abstract, non-extern methods must have bodies

That seems to suggest that non-abstract, non-extern methods in interfaces can have bodies (“must implies can”, kind of a programmer’s variant of Kant’s argument from morality).

And sure enough, this will compile:

interface Agreeable {
    public bool concur() {
        return true;
    }
}

What’s going on here?  Simple: reusable code.

Vala interfaces are much more than hollow declarations of required methods.  Interfaces are full-fledged members of the object hierarchy, able to provide code to inheriting classes.  The reason an interface is not an abstract class is that an interface has no storage of its own, including a vtable.  Only when an interface is bound to a class (abstract or concrete) is storage allocated and a vtable is declared.  In other words, while the above is legal, this is not:

interface Agreeable {
    bool yep = true;

    public bool concur() {
        return yep;
    }
}

gets you this:

error: Interfaces may not have instance fields

Bingo.  That boolean is a member instance, which requires instance storage, which an interface does not have by itself.

So what good is allowing an interface to provide reusable code if it has no fields of its own?  There’s a number of patterns of use, in particular Facade-style methods.  For example, an interface could declare a handful of abstract primitive methods and offer a helper method that uses them in concert according to contract:

interface Agreeable {
    public abstract bool concur(int i);

    public abstract string explanation(bool concurred);

    public void process(int i) {
        if (concur(i))
            stdout.printf("Accepted: %d %sn", i, explanation(true));
        else
            stdout.printf("Not accepted: %d %sn", i, explanation(false));
    }
}

class OnlyOdds : Agreeable {
    public bool concur(int i) {
        return (i & 0x01) == 0x01;
    }

    public string explanation(bool concurred) {
        return concurred ? "is odd" : "is not odd";
    }
 }

class OnlyMultiplesOfTen : Agreeable {
    public bool concur(int i) {
        return (i % 10) == 0;
    }

    public string explanation(bool concurred) {
        return concurred ? "is a multiple of ten" : "is not a multiple of ten";
    }
}

First, note that the implementations of concur() and explanation() in the classes don’t use the override keyword even though you must use the abstract keyword in the interface.  I’m not sure of the reasoning, but so it goes.

Also know that virtual methods, signals, and virtual signals have their own peculiarities with interfaces.  I’ll deal with them in another post.

So, a pretty contrived and very silly example, but notice how process() understands Agreeable’s interface and contract and hides those details behind a single method call.  This is useful.

Going back to those language specifications earlier, remember that Java and C#’s interfaces cannot contain static methods.  In Vala they can:

interface Agreeable {
/* ... */
    public static void process_many(Agreeable[] list, int i) {
        foreach (Agreeable a in list)
            a.process(i);
    }
}

This allows for binding aggregator-style code with the interface itself, rather than building utility namespaces or classes.  Again, this is useful.

However, if the following code is written:

Agreeable[] list = new Agreeable[2];
list[0] = new OnlyOdds();
list[1] = new OnlyMultiplesOfTen();

Agreeable.process_many(list, 10);

you get this compiler error:

error: missing class prerequisite for interface `Agreeable',
add GLib.Object to interface declaration if unsure

What’s this about?

It’s due to another freedom in Vala that is lacking in Java and C#.  Vala classes don’t have to descend from a single master class (i.e. Object).  Unlike the other two languages, if a Vala class is declared without a parent, there is no implicit parent; Vala registers the class with GType as a fundamental type.  If you don’t know what that means, read this.  You probably still won’t know what that means, however.

Because Agreeable is declared without a prerequisite class, Vala can’t produce the appropriate code to store it in a tangible data structure, in this case, an array.  (Update: As Luca Bruno explains in the comments, this is because of Vala’s memory management features.)  This solves the problem:

interface Agreeable : Object {

What this means is that any class that implements Agreeable must descend from Object (i.e. GObject), meaning we need to change two other lines in the code:

class OnlyOdds : Object, Agreeable {

class OnlyMultiplesOfTen : Object, Agreeable {

Although Agreeable now looks to descend from Object, it does not.  It merely requires an implementing class to descend from Object.  (A subtle difference.)  Interfaces can also require other interfaces, and like classes, it can require any number of them:

interface Agreeable : Object, Insultable, Laughable {

Like requiring Object, this means that any class implementing Agreeable must also implement the other interfaces listed (Insultable, Laughable).  This does not mean that Agreeable must implement those interfaces’ abstract methods.  In fact, it can’t, one place where code reuse can’t occur.

Prerequisites also mean that Agreeable’s code can rely on those interfaces in its own code, and therefore can do things like this:

interface Agreeable : Object, Insultable, Laughable {
/* ... */
    public void punish(int i) {
        if (concur(i))
            laugh_at();
        else
            insult();
    }
}

… where laugh_at() is an abstract member of Laughable, insult() is an abstract member of Insultable, and of course concur() is its own abstract member.  In other words, because Agreeable knows it’s also Insultable and Laughable, it can treat itself as one of them.

It’s easy to go crazy with interfaces, prerequisites, and helper methods, but most great languages have their danger zones of excess and abuse — features that are the hammer that makes everything look like a nail.  Still, I think code reuse is the most important goal of any programming technology — language, tool, or paradigm — and I’m glad Vala has given it some thought in terms of interface.

PirateBox at Yorba

The strangest item on my desk — at the moment — is a PirateBox.

What is a PirateBox, you may ask?  At first glance it appears to be a Jolly Roger lunch box plugged into the wall.

But it’s more than that; it’s a wifi network for sharing files locally. All you have to do is point your wifi-enabled device at the “PirateBox” network, open a browser and try to load any page. You’ll be directed to a list of files to download and given the opportunity to upload your own.

At the moment, it’s filled with an assortment of video game music, an important textfile about Pascal, and a free album by gangsta nerd rap superstar ytcracker.

It’s all anonymous, at least as anonymous as any unsecured wifi network can be. The device isn’t connected to the internet so you have to be in (or very close to) our office to use it.

I built the box using an router capable of running open source firmware, following directions on the official PirateBox wiki. The storage is all on a cheap USB thumb drive.  Everything was installed and assembled at our local hackerspace, just around the corner from the office.

As far as hobby electronics projects go this one is pretty simple to do, relatively cheap (less than $150 USD) and occasionally exciting as unexpected new files show up.

Computer problems

I was having trouble with my computer — it didn’t want to boot.  So I opened it up, and look what was inside!


Not sure where the little guy came from, but in any event we’ll have to keep him away from computers.  Won’t be a problem for long though, as in the near future he’ll be embarking on a series of travels.

A few of my favorite Vala things: enums

Working with Vala for over two years now, I’ve come to admire more and more of its language features.  Some of them were quite surprising when I discovered them, making me wonder why exactly they were implemented this way or that.  Once I dug through the learning curve, I came to understand and appreciate their power.  One of those language features is enum.

Enumerated types, of course, have been around for quite a while.  In many languages they’re little more than auto-generated constant int’s (<cough> C </cough>) while in others they have more type safety and correctness surrounding them (such as Java’s approach, which takes enums to the extreme).  Vala takes an interesting middle ground in this field.

On one hand, enums in Vala are much like C’s enums; they can be treated as ints, plain as day, and convert back and forth with amazing ease:

enum Suit {
 SPADE,
 HEART,
 DIAMOND,
 CLUB
}

void main() {
 Suit suit = Suit.SPADE;
 int i = suit;

 stdout.printf("suit=%d i=%dn", suit, i);
}

Personally, I’d prefer it if at least a cast was required, but that’s a nit.

What’s useful about enums is that Vala provides an automatic to_string() method for them, just like int, but with a twist:

stdout.printf("suit=%s i=%sn", suit.to_string(), i.to_string());

Produces:

suit=SUIT_SPADE i=0

Very handy for debugging! Unfortunately, SUIT_SPADE is not such a great text label for your soon-to-be-famous GTK+ War! card game. It turns out you can override the to_string() method by providing your own:

enum Suit {
    SPADE,
    HEART,
    DIAMOND,
    CLUB;

    public string to_string() {
        switch (this) {
            case SPADE:
                return "Spade";

            case HEART:
                return "Heart";

            case DIAMOND:
                return "Diamond";

            case CLUB:
                return "Club";

            default:
                assert_not_reached();
        }
    }
}

Note some important things here:

  • The semicolon must be used to end the list of enumerated values;
  • although you’re “overriding” Vala’s built-in to_string() method, you don’t use the override keyword (unlike Java, enums are not a class nor derived from one);
  • use assert_not_reached() (or some debugging/logging action) in the default case, as Vala allows for transparent casting of bare ints to enums.

That said, this is pretty slick now.  enum now looks more like it’s object-oriented brethren than a third cousin twice-removed.  And Vala goes all the way with this, allowing any number of methods (member and static) be added to an enumeration:

enum Suit {
    SPADE,
    HEART,
    DIAMOND,
    CLUB;

    public string to_string() {
        switch (this) {
            case SPADE:
                return "Spade";

            case HEART:
                return "Heart";

            case DIAMOND:
                return "Diamond";

            case CLUB:
                return "Club";

            default:
                assert_not_reached();
        }
    }

    public bool is_higher_than(Suit suit) {
        return this < suit;
    }

    public static Suit[] all() {
        return { SPADE, HEART, DIAMOND, CLUB };
     }
}

void main() {
     stdout.printf("%s > %s?  %s.n", Suit.SPADE.to_string(),
        Suit.HEART.to_string(),
        Suit.SPADE.is_higher_than(Suit.HEART).to_string());

    foreach (Suit suit in Suit.all())
        stdout.printf("%sn", suit.to_string());
}

Produces:

Spade > Heart?  true.
Spade
Heart
Diamond
Club

By riding this middle ground (enums really just ints under the covers, but extensible with methods) Vala offers some of the power and flexibility that a Java-like language has while still producing C code compatible with other languages (useful when building a library).  In fact, the automatic to_string() method works even with enums from non-Vala libraries (i.e. GLib, GTK, etc.); valac generates the function for you (that is, the library doesn’t have to supply one, although if it does, you can patch it in via its VAPI).

The above code sample points to the other item I would throw on the enum wishlist: either an automatic method (like to_string()) that returns an array of all enumerated values, or simply make the type name iterable:

    foreach (Suit suit in Suit)
        stdout.printf("%sn", suit.to_string());

I realize this looks wrong in so many ways, but so does switch(this) when you first encounter it. Whatever the syntax, iterating over all the values of an enumerated type is a common task, and manually maintaining an array (as in the above example) is error-prone.

Addendum: Eric ran into a bug with enums and to_string() that’s worth mentioning: if you call an implicit (i.e. auto-generated) to_string() from within an enum method, you currently have to use this, that is, this.to_string().  The bug is reported here.

Update: There is an outstanding Vala ticket for allowing foreach to iterate over all enums.  A patch was recently submitted, so it’s possible this will be coming soon.

Vala delegates under the hood

On the Vala mailing list someone wondered if delegates are merely function pointers, not some higher-level concept.  This was in the context of a blog post earlier this year speculating (accusing?) Vala of infringing on Microsoft patents.  I won’t step into the legal morass of software patents under United States law, but it’s important to know: delegates are not merely function pointers.  Understanding how delegates differ from function pointers makes for a better understanding of their power.

Consider the common C++ dictum against taking pointers of non-static functions (that is, methods, which are different than pointers to member functions, C++’s mangled way of dealing with this problem).  A method pointer is near-useless without a corresponding this pointer (which must be manually passed on the stack).  And pointers to virtual methods bypass the vtable, which is itself dangerous for a bunch of reasons.

Delegates solve these problems in an elegant way.  In order to do this, a delegate bundles together a this pointer (which Vala calls the target and is null for a static delegate) and a function pointer.

However, the delegate’s function pointer is not merely pointing at your callback.  Instead, Vala passes a pointer to a hidden delegation function which calls the “real” function.  The delegation function re-sorts the callback’s parameters to move the user data pointer (which can be anywhere on the stack, and is often last in GLib) to the first parameter for the real callback (making it the this pointer).  If the delegate is for a virtual function, this “real” function in turn calls through the object’s vtable (which is a function pointer stored in the object’s instance structure).

These levels of indirection means delegates just work (with some notable exceptions).  Because this binding happens late (i.e. at run-time), you can pass delegates around in constructors before the child class has completed initialization (although there’s some danger there, obviously).  If Vala later adds deeper mixin support, late binding means delegates still work.

What’s cool about Vala is how this is all laid out visibly in C.  Perusing the C code makes it easy to learn how modern object-oriented features are implemented down at the metal.  In essence, Use the Source Luke has two meanings with Vala: you can glean language features by examining the compiler or the code the compiler generates.