I agree with Roy's basic point, but I think the ex...

2008-03-05T06:12:00.000-08:00

I agree with Roy's basic point, but I think the example is poorly chosen. Whether to render an object as HTML or a JSON object is not a choice the object should be making, it's a choice that the high-level code should be making based on the context in which the object is being serialized.

I was one of the people that thought that your arg...

2008-03-03T03:12:00.000-08:00

I was one of the people that thought that your argument was a straw man and I think that this is pretty much just a repetition of it, let me make this clearer.

Interfaces allow you to control the environment that a function can be called in: You can specify which type something has. That is based on the idea that you have a set of classes already defined that model your whole area of interest.

In dynamic languages you (well "I") don't think like that: You know that you will not have "controlled environments" so (because "it's easier to ask for forgiveness than for permission") you just do what you want to do and handle the errors. That's not lazy, that's the way those languages work and that's the idiomatic way to use them.

You can use constructs like "assert" (Ruby probably has something similar) to control the environment but that would bloat the code and make it harder to understand so it should be avoided.

Raise/Throw meaningful exceptions that tell you what is wrong. When writing a function write in the docstring/comment for it, what "things" it can handle, use tests to make sure it all works together.

So I do agree somewhat: You want some documentation about what some function expects, but putting it in the code with interfaces (or the workarounds you already presented) is very unidiomatic for dynamic languages and should be avoided.

Comments on thisDev: Quacking Again - More On Duck Typing

I agree with Roy's basic point, but I think the ex...

I was one of the people that thought that your arg...