Comments on thisDev: The Myth of Duck Typing

The main distinction between Duck typing and inter...

2008-03-03T18:19:00.000-08:00

The main distinction between Duck typing and interfaces is that objects can guarantee that they respond to a "contract"; i.e., a whole collection of methods, rather than a single one. I also think your example is a little artificial - I don't generally want the compiler arbitrarily choosing among multiple interfaces to an object. And even when it does, you're most likely going to have conditional code based on the type of interface you got.

Real systems are generally built with specific implementations in mind; certainly they have to be tested against specific implementations. I have always felt that building "plugable" interfaces that work across unknown implementations is an elusive goal. The only places it's been done successfully is when a) one side of the implementation has an established standard against which to test, and b) the interfaces are kept very simple.

I think Microsoft's experiment with OLE (and Apple's experiment with AppleScript) has shown the fragility of trying to integrate highly complex objects exposing a myriad of interfaces.

By the way, your example brought to mind the elegant way that Prototype (javascript library) handled returning an interface to the XMLHttpRequest object:

var Ajax = {
  getTransport: function() {
    return Try.these(
      function() {return new XMLHttpRequest()},
      function() {return new ActiveXObject('Msxml2.XMLHTTP')},
      function() {return new ActiveXObject('Microsoft.XMLHTTP')}
    ) || false;
  },

  activeRequestCount: 0
}

var Try = {
  these: function() {
    var returnValue;

    for (var i = 0, length = arguments.length; i < length; i++) {
      var lambda = arguments[i];
      try {
        returnValue = lambda();
        break;
      } catch (e) {}
    }

    return returnValue;
  }
}

Note that it's important to control the order in which each interface is selected - a built in language feature would not necessarily control that for you. I think the Try.these() paradigm is a good one for wrapping Duck typed object of unknown origin.

Good post.

I started in Smalltalk which I l...

2008-03-02T07:33:00.000-08:00

Good post.

I started in Smalltalk which I loved for a long time. When Java started on the scene I saw the benefits of strong typing that you support in your post. But after using Java for the past 7 years, I am loving the comeback of dynamic typing languages like Scala.

This is really one of those arguments that is totally subjective and hence can't be won.

To each his/her own.

I can't resist to bring this to notice: Duck typing done right.
Scala is very promising :)

Final comment: the idea of a compile time is incom...

2008-02-29T13:56:00.000-08:00

Final comment: the idea of a compile time is incompatible with Ruby as currently implemented!

And if you are concerned about code being changed, you should be running tests, which IMHO, are the only way to ensure that your code doesn't modify itself and remove a needed method at runtime. Like I said, Java can do it via reflection, even C can do it via twiddling with the dispatch table.

Rob: I also forgot to mention that if you want int...

2008-02-29T13:50:00.000-08:00

Rob: I also forgot to mention that if you want interfaces, then you should be using a mixin. So to implement obj.render, I'd want to implement a mixin for the different types of rendering.

Jorge: Just wanted to point out that you cannot ch...

2008-02-29T13:47:00.000-08:00

Jorge: Just wanted to point out that you cannot change the type of an object at runtime. You can change it's methods, which is unrelated to duck-typing. Using reflection, I can do that in Java. You can change the variable's type, except that variables don't have type. Only objects have type.

Rob: I agree that this type of respond_to? chaining is wrong. But I think that a better technique would be to define a render method and call obj.render, and let the object do it's rendering. But that's just me

commons_guy: I don't agree it's a strawman....

2008-02-29T12:34:00.000-08:00

commons_guy: I don't agree it's a strawman. This is a real case. I have a list of objects (of unknown types) and render them. Many of the classes I create support to_html, but not all of them. Why shouldn't I be able to handle it gracefully?

Your implementation below doesn't have the same functionality as my examples. Make it match and I'll gladly post it in an update with proper formatting (why doesn't Blogger support the pre tag in comments?). And you're using nil as a magic value. What if the methods we're calling return nil as a valid result? Neither of the examples have a problem with that.

"But when I know I need a particular interface (no...

2008-02-29T12:23:00.000-08:00

"But when I know I need a particular interface (not a class), why can't I tell the compiler so it can enforce it?"

Because any such type-checking at compile-time would be useless. Suppose class C implements interface I at compile-time. At run-time, however, I dynamically remove a method from class C, such that it no longer implements I. Then all your compile-time type-checking is rendered useless.

I'm not against compile-time type-checking. I just think it is fundamentally incompatible with Ruby's goals and philosophy. (It's one of the reasons I don't use Ruby.)

"And as for those strings read in from the command...

2008-02-29T12:19:00.000-08:00

"And as for those strings read in from the command line that get evaled? Great idea for a dev tool. Bad idea for a server. Ever hear of "SQL Injection"?"

$SAFE should cover you in many cases. Bear in mind that some Ruby templating engines use eval() to achieve their ends.

"Here's a challenge. Write your version of render(obj) that doesn't use respond_to and has the same functionality"

I'd call a render(obj) method that isn't told what it's supposed to be rendering a code smell. You've created a straw man, then are trying to make your point by claiming it's made of straw.

Moreover, your alternate implementation is indeterminate for objects that implement multiple interfaces (e.g., IConvertsToHTML and IConvertsToJSON).

But, since you insist...and forgive the probably awful formatting from Blogger's edit pane:

def send_or_nil(obj, msg)
begin
obj.send(msg)
rescue NoMethodError
nil
end
end

def render(obj)
result=nil

[:to_html, :to_json].each do |m|
result=send_or_nil(obj, m)
break if result
end

result ? result : obj.to_s
end

You might consider moving the array of symbols somewhere that'll be easier to find. You could open Object and implement send_or_nil() on it instead of having it in whatever class implements render().

Thanks for the feedback, everybody! A couple of th...

2008-02-29T08:59:00.000-08:00

Thanks for the feedback, everybody! A couple of thoughts.

Jorge: I'm not saying Ruby should disallow changing object types at runtime or that it should disallow having completely untyped variables. But when I know I need a particular interface (not a class), why can't I tell the compiler so it can enforce it? Isn't it the job of compilers to take work off of programmers?

And as for those strings read in from the command line that get evaled? Great idea for a dev tool. Bad idea for a server. Ever hear of "SQL Injection"?

Tante: Here's a challenge. Write your version of render(obj) that doesn't use respond_to and has the same functionality: 1. If the object can convert itself to HTML use that; 2. If the object can can convert itself to JSON, use that; 3. Otherwise, generate HTML from the object using to_s; 4. Don't hide any errors by masking exceptions other than those necessary to determine 1 & 2. Bonus points if you make it easy to add extra cases in the future, like generating HTML from XML that the object provides.

My version of this is pretty ugly. If you write a good example, I'll add it to the post.

Dave: You're right. I didn't mean to imply that you supported using respond_to? regularly. Sorry. That section does have one of my favorite footnotes. I also use respond_to? rarely, but I would like not to use it at all because every time I do use it, the compiler could have done it for me.

To be fair, I don't really advocate respond_to in ...

2008-02-29T07:03:00.000-08:00

To be fair, I don't really advocate respond_to in the book: I just say that it's available, and show how you could use it. At the end of the section, I say "However, before going down this path, make sure you're getting
a real benefit---it's a lot of extra code to write and to maintain."

I personally use respond_to very rarely.

Dave

I personally come from a Python background but I g...

2008-02-29T04:21:00.000-08:00

I personally come from a Python background but I guess it's somewhat similar so I'll respond here.

If I'm not mistaken, respond_to? is the check whether a certain object has a certain method/attribute.

Using that is just not very good style from a duck typing background. There's the saying "It's easier to ask for forgiveness than for permission" and it applies here:

You don't check first and call then, that leads to ugly code.

if you have an instance i with three serializers "to_html", "to_json" and "to_xml" for example, you'd just call the serializer you need at that moment:
If you need json, call the appropriate serializer, if there is an issue, you get the exception that tells you what is wrong. If you want things like a hierarchy of serializers as "If json doesn't work, gimme XML and if that fails gimme the string", wrap that in a function and just call that.

The idea of the necessity of checking before calling comes usually from people that have a strong Java/C# background, because they feel they have to do manually what in Java/C+ the compiler does. But that is not how you program dynamic languages, that is trying to make them Java. Which they ain't.

You say:

"And what if the compiler could ch...

2008-02-29T03:35:00.000-08:00

You say:

"And what if the compiler could check variables passed to methods to see if they support the requested interfaces and give you compile-time errors instead of runtime errors? ... None of this is fundamentally incompatible with Ruby."

Compile-time type-checking is indeed fundamentally incompatible with Ruby, because Ruby allows you to change the type of an object at run-time. With Ruby, you can't know the run-time type of an object at compile-time.

Consider code like:

def myMethod(MyInterface i)
...
end

obj = eval "MyClass.new"

myMethod(obj)

We know that the type of "obj" is "MyClass", so we can determine whether or not MyClass implements MyInterface. But what if the string passed to "eval" is read in from the command-line or from a file? How would you determine the type of obj at compile-time?

Clearly, I didn't provide the best example. I was ...

2008-02-29T00:41:00.000-08:00

Clearly, I didn't provide the best example. I was trying to keep it short and I threw in the exception as the third option to show how that shouldn't be necessary with optional typing. I've updated the post with a better example.

The point isn't about respond_to? (A purist could even argue that respond_to? shouldn't exist -- we should just try the method in question and rescue if it throws an exception).

The problem is the inability to specify requirements for variables and parameters when they are known. People use respond_to? to work around this deficiency.

I don't want my code throwing exceptions at runtime, especially on a server. I don't want the "or it doesn't" half of the "if it quacks" statement. I want the language, the system, and the compiler to make me more efficient and to help me avoid stupid mistakes.

I agree that this use of respond_to? is horrible, ...

2008-02-29T00:11:00.000-08:00

I agree that this use of respond_to? is horrible, but this is not a good demonstration of duck typing. It's not duck typing if you have to check to make sure it quacks. It should either quack or it shouldn't. If it quacks, then it works. If it doesn't quack, it should throw its own exception. That is, you shouldn't have to throw your own if it doesn't quack. That's done for you already. Also, this whole deal where you try a different method if the first doesn't work… that seems to be some tight coupling, which is kind of making it miss the whole point.