Type-clarifying comments and type checking in dynamic languages

Question

I often feel that there's something wrong when I code blocks such as:

function foo (arg){ // arg: a SomeClass object
    ...
}

or

function foo (arg){
    if (Object.prototype.toString.apply(arg) !== '[object Array]')
        throw new Error("Parameter must be an array");
    ...
}

. With a statically typed language I wouldn't have to either clarify the expected argument type or check compliance to this expectation. In addition, the possibility of specifying a return type makes the code even more descriptive.

OTOH some cases lend themselves to self-documenting code:

function parse (json){
    ...
}

. In the example above, it's reasonable enough to suppose that your API consumers will know both what the function is supposed to do, and what argument values will be acceptable.

However other times clarifying the code intent by choosing "clarifying" names would yield long, awkward names that mix the expected type of a variable and its role.

Am I using dynamic languages with the wrong mindset?

What conventions, techniques, patterns can save one from having to write ugly type-checking code and/or excessively depending on comments?

Answer 1

Here's the thing.

Statically-typed languages normally have a compiler, and the compiler does type checking to prevent a certain class of bugs at compile time - that is, if you have one of those bugs in your code, you won't even get a chance to run into it in production, because you won't have anything to execute until you fix the bug. This is probably the biggest benefit of static typing.

Dynamic languages (often) do not have a compiler, and consequently, any type checking you might want to do happens at run-time, and if your types don't work out the way you expected, you can only find out through testing. But guess what, if you don't type-check at all, you can also find bugs through testing. The added value of type checking, thus, is zero.

The usual way to go about these things is captured in the Python mantra "easier to ask forgiveness than permission" - instead of checking the types of your arguments, you assume that they are correct, and when this causes problems, you catch the exception and recover.

The idea of duck typing is closely related: I don't care about your type, as long as you implement the methods I need.

There are two downsides to the dynamic approach that you need to be aware of: side effects (when asking forgiveness, you also need to clean up all the side effects you've caused so far), and accidental naming clashes (data.save("example.txt") is conceptually different from rescueBoat.save(swimmer))

Answer 2

Am I using dynamic languages with the wrong mindset?

I think so, yes. Worry less about what type it is and more about what functionality it provides.

You can usually check this explicitly at runtime. For example, In Ruby, you can call respond_to on any object and find out if it is capable of responding to the methods you intend to call. Or you can just call the method and it will fail if it can't handle it.

This is known as duck-typing, if you want to search for more info.

Answer 3

If the argument is 'aDuck', and it '.quack();'s like a Duck and it '.walk()'s like a Duck, then saying that it's of type 'Duck'... might be redundant and misleading, as there may also be other classes completely unrelated to Duck that also '.quack();' like a Duck and '.walk()' like a Duck.

Meaningful names and automated regression tests can be quite useful.

If someone calls your method with something very un-Duck-like and it doesn't work the way they expect, then certainly their tests will fail. And they may learn to do something more appropriate to their needs.

So: Write good code. And don't worry about it too much. ;->

Answer 4

I think your mindset is fundamentally sound, as long as you don’t overlook the advantages that a dynamic language gives you amongst which are the reduction in boilerplate, the ability to handle impedance mismatches such as database access and localised expressiveness.

One small tip is to encapsulate the run-time type checking in the form of an assertion. This makes the role of the checking code obvious and is effective when used in conjunction with unit tests.

However, static type declarations do not just provide the means for a compiler to perform a basic set of mandatory unit tests they provide a lot of information to the coder about objects they are using and methods they are calling. Also, providing the assertions and tests to make up for the absence of a compiler’s type checking takes effort, repeated over and over again. I would rather have a single keyword to indicate a type than many lines of assertions and tests.

Although dynamic languages can be very expressive at local level, say within a function, they are far less effective at showing the relationships between components in a large code base. I would rather examine the details of and relationships between objects as revealed by the code in a set of class declarations than examine a bunch of procedural production code and unit tests which may or may not be complete.

I was recently maintaining some unfamiliar javascript code which involved manipulating a tree which was based on some JSON loaded from a server. I had no idea what was guaranteed or even expected about any given node in the tree. A class declaration would have at least given the original developer somewhere to hang information about the expectations about various nodes.

Whereas I might prefer to write in a dynamic language, I certainly prefer to read and maintain code in a statically typed one.

Answer 5

My general experience is that 90% of time the role name implies the type. E.g. you may have User class appear as "creator", "owner", "editor" and simply "currentUser" over and over in given application. If you use those identifiers for the roles consistently and take a little bit of care to avoid naming roles of different types similarly (e.g. don't use "owner" for parent objects if you used it for user owning document), anyone using the interface will learn what type of objects should go where quite fast.

Much of the rest will be obvious from context, especially if you also call actions consistently. Using long names or just accepting the name is not descriptive and adding enough documentation should do for the few cases that remain.