Talk Like A Duck: Tag ducks

On Ceremony and Training Wheels

Rick DeNatale — Sun, 18 May 2008 10:15:00 -0400

The perennial topic of getting duck-typing in ruby has come up again. A ruby nuby wonders about the dangers of passing a “giraffe” object to a method expecting an “order.” Or asking an object to “draw”, expecting it to be a “brush” when it was really a “cowboy.”

These are reasonable questions, coming from someone who is used to a high-ceremony language which gives at least the illusion of protection from such “errors.” Note that method signatures in languages like Java can’t really protect from a draw method doing different things in different classes.

J. Cooper offered the following good advice:

Instead, look at it like this: how likely is a Giraffe able to do what an Order does? If the Giraffe doesn’t quack like an Order, than an exception is going to be thrown automatically anyway.

Just program in it, and see how often it ever actually bites you. Start with small things, work your way up.

The advice here is to tackle the problem of learning a language like Ruby with a certain amount of fearlessness. This reminds me of learning to ride a bike.

The traditional way of learning to ride a bicycle is to use training wheels, sometimes even progressively. Your dad might have installed the training wheels so that they touched the ground, turning the bike into a kind of tricycle with an extra, overly large back wheel between the normal ones. You think you’re riding a bike, but you’re really still on a trike.

The next stage, is for dad to raise the training wheels a bit so that you need to start learning to balance properly, but you can’t really tip too far. Now you’re riding something that kind of acts like a bicycle, but which “flops over” into tricycle mode.

If you never get past this stage, you never really learn to ride a bike. In an analogy with programming in Ruby, training wheels are chicken typing devices.

The truth is that bicycles and motorcycles operate quite differently than wheeled vehicles which keep three or more wheels on the ground, for one thing you steer by leaning, not with the handlebars or steering wheel. Learning to fly an airplane gives even stronger examples of having to learn that your instincts are wrong, and that you have to train yourself to “instinctively” know not only that you turn by banking rather than with the rudder, but that you control altitude primarily with the throttle, not the elevators, speed primarily with the elevators not the throttle, and so forth.

Now the use of training wheels, or flight simulators, might be considered a ceremony, although a necessary rite of passage for many learners. Given the high cost of mistakes in learning, it’s no doubt a good thing that student pilots get time in simulators and in dual control planes accompanied by a flight instructor before soloing. Although the way most young birds learn to fly is to be throw out of the nest to “sink” or “swim” so to speak.

In learning to program, it’s hard to see a difference between a simulator and reality, so it’s perfectly feasible to “fly the plane” from the start. The consequences of a mistake are no more dire than making a mistake in a flight simulator. It’s really just a matter of conquering fear, not to rely on chicken-typing, and the more mistakes you make and correct, the more quickly you come to grips with the differences in really using a dynamically typed language from earlier experiences.

Some can do this easier than others. For example, Alex, my 6-year old next-door neighbor recently jumped off his tricycle, and onto a bicycle (sans training wheels) and is now zooming around our cul-de-sac faster than ever before.

So if you’re struggling with how to program Ruby or a similar language because lacking ceremonial training wheels to “bridge the gap” from Java or a similar language. Might I suggest that you just jump in like Alex and give it a whirl.

Of course, it’s rarely easy to be as fearless as a 6-year old!

Chicken Typing Isn't Duck Typing

Rick DeNatale — Mon, 22 Oct 2007 10:43:00 -0400

Stress
© David Friel

Trans just posted a question on ruby-talk.

It seems that he uncovered a conflict between the facet's library and the Ruby standard open_uri library. Open-uri defines a module called Meta which it uses to extend certain StringIo instances. The Meta module adds several methods including one called meta, which returns a hash of meta information. In two places in open_uri, the message "respond_to? :meta" is used to test whether a particular StringIO instance has been extended.

The problem is that Facets also defines a method in either Object or Kernel called meta which provides a clever way to access the singleton class of an object. So the respond_to? in open_uri was getting false positives.

Trans asked "So where lies the fault in this conflict? Are extensions the bad guy, or is respond_to? really not a good oop concept? Or..?"

David Black replied that he thinks "this is just the age-old issue about adding methods to existing classes and hitting conflicts. #respond_to? is relatively dumb; it can't tell you what the method actually does. I think of it as an important tool for "soft" duck typing, in contrast with "hard" duck typing where you just send the object the message. "

Reading this made me realize that a much better name than "soft" duck typing, for using kind_of?/is_a?, respond_to?, or other such "sniff first" techniques, is Chicken Typing

Chicken Typing Isn't The Dynamic Equivalent of Static Typing

From what I've observed chicken typing is a "safety blanket" technique used by programmers experienced in statically typed languages, who seem uncomfortable with making the paradigm shift needed to really make dynamically typed languages work.

But because Ruby is dynamically typed, such techniques work imperfectly at best. Here are some of the problems:

Checking with respond_to? can give false positives like this because just because an object has a method with the name you are looking for, doesn't mean that the method has the semantics you expect
Similarly respond_to? can give false negatives when methods are implemented dynamically via method_missing. Chicken typers try to enforce conventions which require overriding respond_to? to get around this, but in general this is difficult, expensive, or impossible to do perfectly.
Checking with kind_of?/is_a? is unnecessarily constraining. In Ruby you don't need the the equivalent to Java Interfaces or Abstract Classes, and once you've really made the paradigm shift from chicken typing to duck typing, you realize that you don't want them.

What's OpenURI Doing?

Because of Trans' question, I decided to look at how OpenURI was using respond_to? in this case. Here's the code in question:

First the beginnings of the OpenURI::Meta module

module OpenURI
 module Meta
   def Meta.init(obj, src=nil) # :nodoc:
     obj.extend Meta
     obj.instance_eval {
       @base_uri = nil
       @meta = {}
     }
     if src
       obj.status = src.status
       obj.base_uri = src.base_uri
       src.meta.each {|name, value|
         obj.meta_add_field(name, value)
       }
     end
   end

   attr_accessor :status
   attr_accessor :base_uri

   # returns a Hash which represents header fields.
   # The Hash keys are downcased for canonicalization.
   attr_reader :meta

   # MORE STUFF....
end

Meta.init causes the object passed as the first parameter to extend Meta, if a second parameter is passed, it's presumably also a Meta, and it's meta attributes are copied to obj.

Now here's the use of chicken typing:

module OpenURI
   #...
  class Buffer # :nodoc:
    def initialize
      @io = StringIO.new
      @size = 0
    end
    attr_reader :size

    StringMax = 10240
    def <<(str)
      @io << str
      @size += str.length
      if StringIO === @io && StringMax < @size
        require 'tempfile'
        io = Tempfile.new('open-uri')
        io.binmode
        Meta.init io, @io if @io.respond_to? :meta
        io << @io.string
        @io = io
      end
    end

    def io
      Meta.init @io unless @io.respond_to? :meta
      @io
    end
  end

A few observations:

The variable which is being chicken typed, in both cases, is an instance variable which is set by the initialize method and never rebound. So there's no concern about checking an object which was handed in, e.g. through a parameter. We might be concerned that someone outside the class might somehow access it and change it to extend Meta without the Buffer knowing about it, but...
The instance variable will always extend Meta after the accessor is called, so the above concern is moot.
In the io accessor method, respond_to? is used to prevent re-extending Meta. This could be avoided by either extending the object referred to by @io in the initialize method, or, if there's a legitimate reason to defer the extension, either adding a state instance variable to indicate that the extension has been done, or just change "unless @io.respond_to? :meta" to "unless @io.kind_of?(Meta)". This is one case where kind_of? is really useful since we're really just checking if code under our control has extended an object under our control, with a particular Module.
Finally, a minor point, but I find this code unnecessarily hard to read because of the choice of name 'io for the temporary in the <.<. method. Look at the line "io.binmode". Which io are we talking about? Is it the io we just assigned, or the result of the io accessor method. Now it happens to be the former, but knowing that requires knowing that the assignment above is what causes the Ruby parser to treat it as a temporary rather than a method send.

Better a Duck Than a Chicken

So in my opinion, it's better to be a bold Duck than a timid Chicken. Chicken typing is weak, and it really doesn't provide much more than the "warm fuzzies". Duck type, and build your specs/tests as you code to provide long-term robustness in dynamically typed languages.

Duck A La Range

Rick DeNatale — Thu, 20 Sep 2007 11:36:00 -0400

Turducken
Public Domain
via Wikimedis Commons

On ruby-talk, Sammy Larbi recently asked if it would make sense to add a length method to Range, something like this:

class Range
     def length
          self.end - self.begin
     end
end

This led to an interesting discussion about the varieties of ranges, and ultimately led me to this article about duck types.

This led to an observation by Xavier Noria that

Ranges don't require their elements to support a "-" method, only :succ and :<=>, so this wouldn't work for all ranges.
A first approximation of a general implementation of Range#length would be to iterate over the elements of the range and count them but..
Some ranges might actually have an infinite number of elements, so length doesn't make sense for them.

Home, Home on the Infinite Range

In thinking about this a bit, I'm not sure that you can have a Range with an infinite number of elements which supports enumeration. Xavier gave a range of rational numbers as an example, but I'm not sure I see how you can define both a :<=>, and :succ methods for rational numbers which make sense. The problem is that although rational numbers are countable, they are also densely ordered.

The fact that rationals are countable simply means that you can pair each rational number with an integer. One proof of this constructs the sequence: 1/1, 2/1, 1/2, 1/3, 3/1, 4/1, 3/2, ...

Now this shows that you can put the rationals into an infinite sequence, and define :succ such that (1/1).succ => (2/1), but if you want to keep the normal meaning of :<=>, you have the problem that 2/1 looks like it is less than 1/2.

The fact that rationals are densely ordered means that for any two rationals a <. b there are an infinite number of rationals, c, such that a <. c < b. Which makes it hard to pick which one should be a.succ.

Now it might be possible to come up with an enumerable infinite range which works, but it hurts my head, and it's not really the main point of this article.

What About Non-enumerable Ranges?

The rdoc for Range includes this:

Ranges can be constructed using objects of any type, as long as the objects can be compared using their <=> operator and they support the succ method to return the next object in sequence.

This is true, if you want to use all of the methods of Range, but one can actually usefully create ranges of objects with support <=> but don't support succ.

1.0.methods.include?(:succ) # => false
(1.0..2.0).include?(1.5) # => true

Floats respond to <=>, but they don't respond to succ. As shown above you can create a Float range, and use it to see if a number falls within that Range. What you can't do is enumerate such a Range:

(1.0..2.0).to_a # => 
# ~> -:3:in `each': can't iterate from Float (TypeError)
# ~> 	from -:3:in `to_a'
# ~> 	from -:3

So what does this have to do with duck typing? It just goes to serve as another illustration of why classes make lousy duck types. It's not just a matter of what an objects class is, in general it's a matter of what the object can do at the time, and that can depend on things other than the class and the methods. The duck in this last example is a bird which can determine whether or not it includes a number, it simply has to quack yes or no when fed a number. It doesn't have to walk along all the numbers it 'contains.'

Whether or not such a duck is useful depends on the user of the duck, not the duck itself.

About That Picture

I searched around to find a non-copyrighted photo of Duck a l'orange, and couldn't find one. I did find one of a Turducken. For those unfamiliar with this bird, it's a boneless turkey, which has been stuffed with a boneless duck, which has in turn been stuffed with a boneless chicken. After thinking about this a bit it seemed appropriate for this article which is after all about the effects of stuffing one object with another.

Our Kind of Ducks, Odd Ducks, and Trained Ducks

Rick DeNatale — Mon, 30 Apr 2007 16:01:00 -0400

A couple of days ago, someone asked on ruby-talk how to implement a cyclic version of Enumerable#each_cons. In words, he was looking for a method:

class Array
   def each_cycle(size, start=0)
      #insert implementation here
   end
end

# So that this:
%{a b c d e}.each_cycle(2) {|cyc| p cyc}

#would print:
["a", "b"]
["b", "c"]
["c", "d"]
["d", "e"]
["e", "a"]

As usual, several helpful rubyists responded with suggestions, one of which leads me to YADTBE (Yet Another Duck Typing Blog Entry)

Here’s one suggested solution:

module Enumerable
  def each_cycle(window, start=0)
    (start...length+start).each do |i|
      yield((i...i+window).map {|n| self[n % length]})
    end
  end
end

Nice solution, but as soon as I saw it, I saw a problem.

While this will work if the method were defined in the Array class, it doesn’t work in general for Enumerables. Let’s write a Kernel method to try some different Enumerables.

def try(enum)
  puts "Trying this #{enum.class} ==> #{enum.inspect}"
  begin
    enum.each_cycle(2) {|cyc| p cyc}
  rescue => ex
    puts ex
  end
  puts
end

Is it a duck?

Okay, now that we’ve done that, let’s try some enumerables:

try(%w{and a one and a two})

# Results in
Trying this Array ==> ["and", "a", "one", "and", "a", "two"]
["and", "a"]
["a", "one"]
["one", "and"]
["and", "a"]
["a", "two"]
["two", "and"]

So this works if the receiver is an Array.

Not the kind of duck we’re looking for

Ranges are Enumerable, so let’s try one.

try(1..5)
# Results in
Trying this Range ==> 1..5
undefined local variable or method `length' for 1..5:Range

Aye, there’s the rub, the each_cycle method assumes that the receiver implements both a length method, and a [] method.

This is the kind of requirement which leads some “strong ducktypers” to use a respond_to? test. But does that really work?

Odd ducks

Well, Hash implements both of those methods, so it would pass the ‘responds_to?’ test. Lets try one:

try(Hash[*(%w{zero, one, two, three}.zip((0..3).to_a)).flatten])
# Which prints:
Trying this Hash ==> {"two,"=>2, "three"=>3, "one,"=>1, "zero,"=>0}
[nil, nil]
[nil, nil]
[nil, nil]
[nil, nil]

Hmmm, not exactly what we are looking for. So it’s not enough to just be an enum with those two methods. We’ve just exposed another requirement of Enumeration#each_cycle, that the receiver be indexed by integers. We’re getting all nils because all of those nicely generated indices don’t have corresponding values in the hash, and hash is lenient about indices (i.e. keys) which aren’t keys.

So what happens if we try a hash which does have integer keys:

try(Hash[*((1..3).to_a.zip(%w{one, two, three}).flatten)])
#now we get
Trying this Hash ==> {1=>"one,", 2=>"two,", 3=>"three"}
[nil, "one,"]
["one,", "two,"]
["two,", nil]

Now, that sort of works, but it exposes yet another requirement, that the indices of the enum be in the range (0…enum.size).

I dub thee Sir Duck

If we use a slightly different hash:

try(Hash[*((0..3).to_a.zip(%w{zero, one, two, three}).flatten)])
# We get
Trying this Hash ==> {0=>"zero,", 1=>"one,", 2=>"two,", 3=>"three"}
["zero,", "one,"]
["one,", "two,"]
["two,", "three"]
["three", "zero,"]

So for a hash which looks enough like an Array, the code in Enum actually works.

Teaching a range to be our kind of Duck

One final example. Let’s revisit the case of a range. We can easily train the range class, or using a singleton class an individual instance of range how to support the each_cycle method:

class Range
  def length
    (last - first) + (exclude_end? ? 0 : 1)
  end

  def [](i)
    first + i
  end
end

# Now if we try this again:
try(1..5)

# We get:
Trying this Range ==> 1..5
[1, 2]
[2, 3]
[3, 4]
[4, 5]
[5, 1]

Okay Rick, what’s your point?

Although this exercise might seem a little contrived, it points out that in a dynamically ‘typed’ language like Ruby, whether or not a particular object is suitable for a particular use can depend not only on it’s class, or which modules are mixed in, or whether or not it responds to a particular set of messages, but on how it responds to those messages.

Using my metaphor of casting for a role in a play, finding the right actor isn’t just a matter of finding someone who went to a particular acting school, (i.e. has (had) the right class or classes), but it’s a matter of fitting the individual to the requirements. It’s akin to being interviewed for a job, for the employer doing a successful ‘type-check’ is a subtle process, and often leads to a probation period (i.e. testing).

Strong-typing advocates will no doubt see this as a flaw in dynamic systems. I see it as a strength. If you think about it honestly, there are a wide variety of requirements which aren’t expressed in strongly typed language, either because the type system doesn’t choose to express subsets of types, such as positive numbers, prime numbers, even numbers, etc.; or because state-oriented requirements such as an open file, don’t really fit into the notion of a static type.

In my experience, I’ve gotten to the point where I rarely make the kind of errors which are caught by static types, and the flexibility of dynamic languages far outweighs the relatively minor benefit of early static type checking. I’d rather rely on a growing set of test cases to fight bugs.

Hungarian Ducks

Rick DeNatale — Mon, 09 Apr 2007 17:07:00 -0400

It’s interesting how events flow sometimes.

One of my major interests outside of software development is human spaceflight. Today I opened the local paper to the coming events section and discovered that the latest ‘rich cosmonaut’ to buy a trip up to the international space station, was arriving there today, and that his name was Charles Simonyi. As I’m writing this, he has just become the first Hungarian in space, or at least that’s what I heard him say over NASA TV.

Update: Actually that honor went to Bertalan Farkas who flew on Soyuz 36 in May of 1980.

Now that’s a familiar name. So I spent a little time this morning looking at his article on Wikipedia, and following some links. Thereby hangs an interesting tale which relates to duck-typing.

Charles Simonyi

Simonyi was the software architect at the Microsoft Applications Division back in the early days of Excel and Word. Before coming to Microsoft he was at Xerox Parc, at the same time as folks like Alan Kay, Butler Lampson, Robert Metcalfe, and Dan Ingalls. One of his most famous inventions was so-called Hungarian Notation, a way of encoding ‘type’ information into the names of variables. This became very popular among C programmers following the Microsoft programming bibles.

Now I never much cared for Hungarian Notation (which I’ll refer to simply as Hungarian for the rest of this article). As normally practiced it led to variable names which looked like they’d grabbed onto part of the C compiler’s symbol table entry. The variables would look like iX, and iY (for two different integer variables), or something like pudwGorp for a pointer to an unsigned doubleword.

Eventually Hungarian fell out of favor as more and more programmers realized that it didn’t contribute enough to pull its weight in ugly names.

Hungarian Dialects

What I learned today was that this form of Hungarian is actually a corruption of Simonyi’s original Hungarian which, instead of encoding the machine representation of the variable, encodes the intentional use of the variable. The Hungarian which most people saw was that used by the Microsoft Systems Division. Those in the know refer to this as Systems Hungarian to distinguish it from Simonyi’s original notation which is known by insiders as Apps Hungarian.

Here, from Simonyi’s original explanation of Hungarian Notation is how variables (or as he called them quantities) should be named:

Quantities are named by their type possibly followed by a qualifier. A convenient (and legal) punctuation is recommended to separate the type and qualifier part of a name. (In C, we use a capital initial for the qualifier as in rowFirst: row is the type; First is the qualifier.)
Qualifiers distinguish quantities that are of the same type and that exist within the same naming context. Note that contexts may include the whole system, a block, a procedure, or a data structure (for fields), depending on the programming environment. If one of the “standard qualifiers” is applicable, it should be used. Otherwise, the programmer can choose the qualifier. The choice should be simple to make, because the qualifier needs to be unique only within the type and within the scope—a set that is expected to be small in most cases. In rare instances more than one qualifier may appear in a name. Standard qualifiers and their associated semantics are listed below. An example is worthwhile: rowLast is a type row value; that is, the last element in an interval. The definition of Last states that the interval is “closed”; that is, a loop through the interval should include rowLast as its last value.
Simple types are named by short tags that are chosen by the programmer. The recommendation that the tags be small is startling to many programmers. The essential reason for short tags is to make the implementation of rule 4 realistic. Other reasons are listed below.
Names of constructed types should be constructed from the names of the constituent types. A number of standard schemes for constructing pointer, array, and different types exist. Other constructions may be defined as required. For example, the prefix p is used to construct pointers. prowLast is then the name of a particular pointer to a row type value that defines the end of a closed interval. The standard type constructions are also listed below.

State Your Intentions

Note that Simonyi here is really talking about the intentional use of the variable rather than it’s representation as a bag of bits.

While this isn’t really a duck-typing system, it relates in that it describes the usage of a variable in priority to the machine representation. Since the host language here is C, the notation still has to talk about things like pointers, and whether or not the pointer is being used as an array.

So in Apps Hungarian instead of iX, and iY, those variables would likely just be x and y if they were being used for x and y positions, or row and col for spreadsheet coordinates. Other names might be wrx for an x position relative to the window coordinate system, or wrxWidget1 for a particular window relative x coordinate.

And the two dialects are incompatible. As explained by Rick Schaut:

For those of us who have grown accustomed to Simonyi-style HN, the whole “i” means “int” prefix thing is doubly horrible, because the “i” prefix in Simonyi-style HN is commonly understood to be an index into an array. If I put a character into an int, I’m not going to call it iCh. I’m just going to call it ch. To me, an ich is an index to a character in an array of characters.

In comparison to System Hungarian, this seems to be much more useful information than a shorthand encoding of the underlying C datatype.

This schism between the two dialects came about because Simonyi used the word type where a better word such as usage or role would have better represented the idea. Perhaps this came from the fact that Simonyi’s native language was, not surprisingly, Hungarian rather than English. It was actually the technical writers in the Systems Division who created Systems Hungarian by editing earlier documentation of the concept without fully understanding it.

It seems to me that this is the same confusion which confounds so many discussions of duck-typing in dynamic languages.

Schrödinger's Duck

Rick DeNatale — Thu, 21 Sep 2006 11:27:00 -0400

Once again there’s been a recent furore about the meaning of Ducktyping on the ruby-lang mailing list.

A nice young man from Sweden, by the name of Ola Bini, announced “ductator” a ruby-gem which allows type validation of ruby variables. Now I think that Ola is young based on the photo on his blog site, and I know that he’s nice because only nice people inhabit ruby-lang.

The real question is just what kind of a type system ductator represents. I’ve taken a brief look at it and it seems to allow one to describe, via a hash, a list of rules which are applied to a variable’s value at run-time. These rules are things like a list of methods the value must have, a class which the value must be an instance of, or an instance of a subclass of etc.

The Cat is Dead, Long Live the Cat

In 1935 Erwin Schrödinger, proposed his famous thought experiment, in which a cat, a a radioactive atomic nucleus, and a cannister of poison gas rigged ot open if the nucleus decayedare placed in a sealed box. The half-life of the neucleus is such that there is a probability of 1/2 of the nucleus decaying within one hour. Because quantum mechanics states that until a decay is observed, the nucleus really exists as a superposition of decayed and undecayed states, that the cat is both dead and alive until the box is open and the observation is made.

Schrödinger’s experiment is really a dramatized version of a similar thought experiment previously published in a paper co-written by Einstein. Although Einstein intended it as a refutation of the probabilistic nature of quantum mechanics, the stochastic basis of quantum mechanics has held up over the ensuing seven decades, and such paradoxes have held up.

My point here is that, in a sense, the kind of type checker represented by ducktator. It attempts to observe certain aspects of an object, and in so doing, has a good chance of killing the duck.

Besides the questions of what duck-typing is or is not, such a set of checks fails under many common usages in ruby.

False Negatives

Relying on responds_to? fails under commonly used Ruby metaprogramming techniques.

It’s very common these days to use method_missing to provide pseudo-methods, or to create methods on the fly. ActiveRecord and other RubyOnRails componentry makes extensive use of this technique.

The problem is, of course, that an instance of a class which uses these techniques effectively gives an invalid response to responds_to?, or may reply false, until the missing method is invoked, creating the method.

Poking around a bit, I notice that some of the standard library classes, and others liek ActiveRecord, go to some lengths to make responds_to? track with phantom methods implemented via :method_missing, although fixing other reflection methods like :methods and the class method :instance_methods doesn’t seem to be commonly done. While this is good, it can greatly increase the expense of :responds_to?. ActiveRecord::Base, aliases :responds_to? as responds_to_without_attributes? before redefining :responds_to? for this reason.

In the case of Drb::DrbObject, which is used as the proxy object in Distributed Ruby, handling :respond_to? on behalf of a remote object, requires marshalling a :respond_to? message to the remote object, sending the marshalled message, then reading and unmarshalling the reply. This makes sending :respond_to? to a remote object much more expensive.

And irony of ironies, ductator uses :method_missing to supply phantom methods in it’s implementation, without implementing a compensating :respond_to?!

False Positives

Even if one accepts the philosopy posited by ductator, using it can get tricky. For example, one might check to see if an object responds_to?(:each), but exactly what :each does and how it interacts with it’s block argument, depends on the class itself. For example, most enumerables yield a single value to the block in :each, but Hash yields both a key and a value. The block can be written to accomodate this, but it doesn’t have to be. It’s not clear to me how to either express or check the type of such block arguments. I don’t see a mechanism in ductator even to check the arity of a proc, and although this could be added, it’s not really sufficient since it doesn’t express the types required of block arguments.

What’s the Value?

Some folks might find something like ductator to their taste, since it give the impression of making Ruby more like Java or C++. The problem is that in so doing, it makes Ruby less like Ruby. This kind of type checking seems to be an expensive add-on to the real checking which happens during program execution. The fact that everything is an object in ruby means that the really nasty errors in a language like C when you use an integer as a pointer don’t happen. It seems to me that the best that something like ductator can do is to make a more ‘meaningful’ error description when something goes wrong, but doing that correctly is harder than it first appears, and in most cases could be accomplished more efficiently by catching errors with rescue clauses and changing the error reporting, after the fact, which puts the cost of the error on the offender rather than taxing everyone with run-time pre-flight tests.

Wrapping up for now

The French word for “duck” is “canard.”

In computer jargon, the word “canard” means a “mistaken and confused belief”. In my humble opinion, the view of duck typing taken by ducktator and its ilk is in this sense really “canard” typing.

Le canard est mort, vive long le canard!

Or translated into English:

The canard is dead, long live the duck!

I'm Ready For My Close-up, Mr. Demille

Rick DeNatale — Tue, 22 Aug 2006 11:37:00 -0400

Back when I was younger, and object[-oriented] programming was fairly new, my colleagues and I seemed to spend a lot of time philosophizing about types and objects. Although I don’t remember talking about ducks, we did talk a lot about the theater. The most common word we used to use for what we now call a duck type was a role.

Another way of looking at this, is that duck typing is akin to the way a person is chosen to fill the role of the American President. An assessment is performed on the candidates,one is chosen, and then the country, and world adapt.

Contrast this to the way things are done in picking the next British monarch, or the type systems of C++ or Java. In both cases one has to be born into the role, having the right genes via inheritance. Of course in the first case, who gets the job doesn’t matter all that much anymore.

Recently a thread about patterns on the ruby-talk mailing list turned, as threads there are wont to do, to duck-typing.

William Crawford, helpfully contributed:

In short, if a type/class/whatever has all the methods of a duck (that you intend to use), it’s a duck and can be used as a duck would be used, regardless of what’s actually under the feathers.

In other words, TCPSocket doesn’t just inherit from Socket, Object, etc… It IS a Socket, it IS an Object, etc.

While this is true, the second paragraph is not a particularly good example to explain duck typing.

Duck typing is not about what an object “is”, but what it can be used for. Whether an object can be used for something depends on who is using it.

Let’s look at DT’s example from the Pickaxe. Cutting the code down to the bare essentials we’ve got:

def csv_from_row(op, row)
   #code to compute res from row
   op << res << CRLF
end

Now what kind of duck does op need to be? Simply an object which accumulates objects via the << method.

His first use was:

result = ""
query.each_row {|row| csv_from_row(result, row)
http.write result
</type:code>

This works, but it's slow as the number of rows gets large. Strings meet the requirements of the op parameter, but they also have other characteristics. The important one here is the subtle effect on GC.  For a more detailed analysis of this see why's article http://whytheluckystiff.net/articles/theFullyUpturnedBin.html

So let's try to find another object which we can put in the role of the op parameter.  Arrays also can be used.  So we have

<typo:code lang="ruby">
result = []
query.each_row {|row| csv_from_row(result, row)
http.write result

However we’ve now got a little problem in that although an array works as the op parameter, http.write probably won’t like it. But that’s easy to fix, just change the last line slightly to accomodate the new duck in the outer context:

http.write result.join

So, getting back to the theater analogy, when we duck type, we’re in a position similar to a director casting for a role in a play. Sometimes, we find a great actor, but we need to subtly adapt the script to fit his style. That’s what’s happening in DT’s pickaxe example.

Ducks Can Be Subtle Birds

Rick DeNatale — Thu, 10 Aug 2006 11:09:00 -0400

One theory I’ve seen defines a “duck type” as a set of messages which an object bound to a parameter or value needs to understand. This leads some, who want to make type-checking happen a bit earler, to propose testing the values of such variables with oneor more respond_to? tests before using the object “in anger.”

But ducks can be subtle…

Sometimes it’s not enough just to have a certain set of methods in a duck’s repetoire.

Let’s look at an, admittedly cooked-up, example:

def reverse_lookup(value, dictionary)
     (dictionary.collect { |kv| kv[1] == value ? kv[0] : nil }).compact
end

The method is intended to return an array containing keys in a “Dictionary” which map to the given value:

irb(main):001:0> load 'reverse_lookup.rb'
=> true

irb(main):002:0> reverse_lookup(1, { 'a' => 1, 'b' => 2, 'c' => 1})
=> ["a", "c"]

Now, I said that this was a “cooked-up” example to illustrate a point about “ducks.” It would probably be more proper to implement a method like keys_for_value in Hash or a module which could be used to extend Hash or other “dictionary” classes.

The point here is that for this implementation of reverse_lookup, the only message sent to dictionary is collect, soaccording to the “respond_to?” theory any object which has “collect” in it’s repetoire is the right species of duck for the dictionary parameter.

So let’s try another duck:

irb(main):003:0> reverse_lookup(1, [1, 2, 3])
=> [0, 1]

Well, it works in the sense that nothing blows up, but the results look strange, where did that 0 come from?

While you weren’t looking, I snuck a debug parameter into my reverse_lookup method to give an “x-ray” view into what’s happening.

irb(main):004:0> reverse_lookup(1, [1, 2, 3], true)
kv = 1, kv[0]=1, kv[1]=0
kv = 2, kv[0]=0, kv[1]=1
kv = 3, kv[0]=1, kv[1]=1
=> [0, 1]

The reason that it works at all with an array of integers is a bit of an anomally due to the fact that Ruby integers define the [] method as a bit reference. When kv is an integer kv¹ and kv⁰ are respectively the least significant, and second least significant bits in the binary representation of kv.

Now let’s try another array;

irb(main):005:0> reverse_lookup(1, [Array, NilClass])
NoMethodError: undefined method `[]' for NilClass:Class
        from ./reverse_lookup.rb:2:in `reverse_lookup'
        from ./reverse_lookup.rb:2:in `reverse_lookup'
        from (irb):4
        from :0

So this doesn’t work at all.

To sum this up, “duck types” aren’t just collections of messages, whether or not an object will work in any given role also depends on subtleties of the semantics of theimplementation of the corresponding methods, and can also depend on the state of the object as well.

Now this shouldn’t be considered a weakness of “duck typing” compared to “strong typing,” or something in-between the two. Strong-typing systems have similar “flaws” for example strongly typing a variable to an integer won’t protect against division by zerowhcn the variable is used as a divisor, nor will it alone protect against out of bounds errors when it’s used as an array index. The errors which aren’t detected by strong-typing is a much larger set than those which are. In languages which provide limited run-time checking of code which has passed the strong-typing “hurdle” the effects can be disastrous. In my humble opinion, the benefits of dynamic typing far outweigh “unlearning” what has been taught by other languages such as C++ and Java.

Bjarne Stroustrup used to quip, in panel discussions over strong vs. dynamic typing (i.e C++ vs. Smalltalk), that he’d hate to be a passenger on a plane which flashed a light labled “message not understood” in the cockpit when the pilot tried to lower the landing gear. I’d hate even more to be a passenger on a plane whose control software seg-faulted under this condition instead because putting the landing gear down caused a buffer overflow.

The real answer to uncovering and routing out errors is testing, testing, and more testing.