JavaScript Duck Typing – How to Use Without Checking Properties and Methods

duck-typingjavascriptpolymorphism

I know javascript uses duck typing and at first I thought this would make polymorphism easy compared to strongly typed languages like C#. But now my functions that take arguments are littered with things like:

if(myObj.hasSomeProperty())

if(myObj.hasSomeMethod())

if(isNumber(myParam))

etc.

This is really ugly to me. I come from a C# background and I find defined interfaces to be much better.

I'm wondering if I'm incorrectly attempting to apply strategies that are effective in statically typed languages and there's some better way to do this in javascript?

I know I could just not check, but tracking down javascript run time errors can be a nightmare since they don't always happen where the error is actually occurring in the code.

Best Answer

How do you use duck typing in javascript without always checking for properties and methods?

Simple: don't always check for properties and methods.

In Ruby, what you are calling is called "chicken typing". In a dynamically duck-typed, language, you simply trust that the caller passes you a suitable object. It's the caller's job to honor his side of the contract.

I know javascript uses duck typing and at first I thought this would make polymorphism easy compared to strongly typed languages like C#.

You are confusing multiple orthogonal axis of typing here. There are four orthogonal axis of typing:

When: dynamic typing (types aren't known and checked until runtime) vs. static typing (types are known and checked before runtime)
What: duck typing (types are based on behavior), structural typing (types are based on structure), and nominal typing (types are based on name)
Can you see them? explicit typing (the types have to be explicitly annotated) vs. implicit typing (types are inferred)
strong typing vs. weak typing – you might have noticed that I didn't give this one a catchy title nor an explanation in parentheses, that's because unlike the seven terms above, which each have a single universally-accepted precise definition, these two terms have about a dozen semi-widely used vague definitions that contradict each other; ideally you should avoid these terms altogether, and if you must use them, precisely define them first

Since you mentioned C#: it is mostly statically typed, but supports dynamic typing through the type dynamic, it is mostly nominally typed, but anonymous types use structural typing, and syntactic patterns (such as LINQ query comprehension syntax) can be argued to be either duck-typed or structurally typed, it is mostly explicitly typed but supports implicit typing for generic type arguments and local variables (although the local variable case is rather strange compared to most other languages, because you cannot just leave the type out, instead you have to give it an explicit pseudo-type var, in other words, if you want an implicit type, you have to explicitly say so). Whether or not C# is strongly or weakly typed is a matter of which definition of the two terms you use, however, note that there can be plenty of runtime type errors in C#, especially because of unsafe array covariance.

I know I could just not check, but tracking down javascript run time errors can be a nightmare since they don't always happen where the error is actually occurring in the code.

Debugging is not an easy skill to learn. There are, however, techniques to make debugging easier, e.g. the Saff Squeeze is a technique described by Kent Beck which uses tests and refactoring for debugging:

Hit 'em High, Hit 'em Low:

Regression Testing and the Saff Squeeze

Kent Beck, Three Rivers Institute

Abstract: To effectively isolate a defect, start with a system-level test and progressively inline and prune until you have the smallest possible test that demonstrates the defect.

Related Solutions

Python Duck Typing – Forgiveness vs Permission and Duck Typing

It really depends on how often you think the exception is going to be thrown.

Both approaches are, in my opinion, equally valid, at least in terms of readability and pythonic-ness. But if 90% of your objects do not have the attribute bar you'll notice a distinct performance difference between the two approaches:

>>> import timeit
>>> def askforgiveness(foo=object()):
...     try:
...         x = foo.bar
...     except AttributeError:
...         pass
... 
>>> def askpermission(foo=object()):
...     if hasattr(foo, 'bar'):
...         x = foo.bar
... 
>>> timeit.timeit('testfunc()', 'from __main__ import askforgiveness as testfunc')
2.9459929466247559
>>> timeit.timeit('testfunc()', 'from __main__ import askpermission as testfunc')
1.0396890640258789

But if 90% of your objects do have the attribute, the tables have been turned:

>>> class Foo(object):
...     bar = None
... 
>>> foo = Foo()
>>> timeit.timeit('testfunc(foo)', 'from __main__ import askforgiveness as testfunc, foo')
0.31336188316345215
>>> timeit.timeit('testfunc(foo)', 'from __main__ import askpermission as testfunc, foo')
0.4864199161529541

So, from a performance point of view, you need to pick the approach that works best for your circumstances.

In the end, some strategic use of the timeit module may be the most Pythonic thing you can do.

Duck Typing, Data Validation, and Assertive Programming in Python

Let me give some guiding principles.

Principle #1. As outlined in http://docs.python.org/2/reference/simple_stmts.html the performance overhead of asserts can be removed with a command line option, while still being there for debugging. If performance is a problem, do that. Leave the asserts. (But don't do anything important in the asserts!)

Principle #2. If you're asserting something, and will have a fatal error, then use an assert. There is absolutely no value in doing something else. If someone later wants to change that, they can change your code or avoid that method call.

Principle #3. Do not disallow something just because you think it is a stupid thing to do. So what if your method allows strings through? If it works, it works.

Principle #4. Disallow things that are signs of likely mistakes. For instance consider being passed a dictionary of options. If that dictionary contains things that are not valid options, then that's a sign that someone didn't understand your API, or else had a typo. Blowing up on that is more likely to catch a typo than it is to stop someone from doing something reasonable.

Based on the first 2 principles, your second version can be thrown away. Which of the other two you prefer is a matter of taste. Which do you think more likely? That someone will pass a non-customer to add_customer and things will break (in which case version 3 is preferred), or that someone will at some point want to replace your customer with a proxy object of some kind that responds to all of the right methods (in which case version 1 is preferred).

Personally I've seen both failure modes. I'd tend to go with version 1 out of the general principle that I'm lazy and it is less typing. (Also that kind of failure usually tends to show up sooner or later in a fairly obvious way. And when I want to use a proxy object, I get really annoyed at people who have tied my hands.) But there are programmers I respect who would go the other way.

Best Answer

Hit 'em High, Hit 'em Low:

Regression Testing and the Saff Squeeze

Related Solutions

Python Duck Typing – Forgiveness vs Permission and Duck Typing

Duck Typing, Data Validation, and Assertive Programming in Python

Related Topic