From: "wardrop (Tom Wardrop)" <tom@...>
Date: 2013-04-01T09:14:09+09:00
Subject: [ruby-core:53855] [ruby-trunk - Feature #8191] Short-hand syntax for duck-typing


Issue #8191 has been updated by wardrop (Tom Wardrop).


I know what duck-typing is, and it's a bit of a stretch to call this duck-typing, but it follows the duck-typing philosophy - "I don't care what you are, but if you can tell me something, I'll use that information. Otherwise I'll make an assumptions or take some other action."

There's nothing inherently wrong with "mixing all kinds of stuff". For example, the logic in a template should, if possible, not care about the type of data it's about to print out, the #to_s method handles that. However, a template may want to avoid printing something if it thinks it'll print something empty or useless. This is what the #blank? method tries to address in Rails. The following are all comparable:

    unless obj.blank?
       "<span class='something'>#{obj}</span>"
    end

    unless obj.empty??? || !obj
      "<span class='something'>#{obj}</span>"
    end

    unless obj.empty? otherwise !obj
      "<span class='something'>#{obj}</span>"
    end

    unless !obj || (obj.empty? if obj.respond_to? :empty?)
      "<span class='something'>#{obj}</span>"
    end

Such a construct as this would also allow you to deal with API inconsistency or differences as well. One set of objects may expose a #length method, while another set may use #count. They may different semantics, but as a programmer, you may not care about those semantic differences in a particular scenario, and just want to get a value.

I don't hit this ALL the time, but enough to make me want to raise this issue. Ruby shouldn't punish me for asking some unknown object for some non-critical information, which it does either by raising a NoMethodError, or making me use cumbersome pre-conditions. If an object can tell me something, I can use that information, if available, to produce a more desirable outcome.
----------------------------------------
Feature #8191: Short-hand syntax for duck-typing
https://bugs.ruby-lang.org/issues/8191#change-38068

Author: wardrop (Tom Wardrop)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


=begin
As a duck-typed language, Ruby doesn't provide any succinct way of safely calling a potentially non-existant method. I often find myself doing (({obj.respond_to? :empty ? obj.empty : nil})), or if I'm feeling lazy, (({obj.empty? rescue nil})). Surely we can provide a less repetitive way of achieving duck-typing, e.g. I don't care what object you are, but if you (the object) can't tell me whether you're empty, I'm going to assume some value, or do something else instead.

I'm not sure what the best way to implement this is. The easiest would be to just define a new conditional send method:

    obj.send_if(:empty?, *args) { nil }

    obj.try(:empty?, *args) { nil }

But that's really not much of an improvement; it's ugly. Preferably, it'd be nice to build it into the language given how fundamental duck-typing is to Ruby. One potential syntax is:

   obj.empty? otherwise nil

The ((|otherwise|)) keyword would be like a logical or, but instead of short-circuiting on true, it short-circuits on some other condition. That condition can be one of two things. It can either wait for a NoMethodError (like an implicit (({rescue NoMethodError}))), proceeding to the next expression if one is raised, or it can do a pre-test using (({respond_to?})). Each option has its pro's and con's.

The implicit rescue allows you to include expressions, e.g. 

    obj.empty? otherwise obj.length == 0 otherwise true

Going with the implicit (({respond_to?})) implementation probably wouldn't allow that. You'd instead need to limit it just to method calls, which is not as useful. The only problem with implicitly rescuing NoMethodError's though, is that you'd need to ensure the NoMethodError was raised within the target object, and not some dependancy, as you could potentially swallow valid exceptions.

The benefit of this over current methods of duck-typing, is that you're not testing a condition, then running an action, you're instead doing both at the same time making it much more DRY.

One other potential syntax however is a double question mark, or question mark prefix. This could act as an implicit (({respond_to?})) pre-condition, returning nil if the method doesn't exist.

    obj.empty??? || obj.length?? == 0 || nil

    obj.?empty? || obj.?length == 0 || nil

I'm not completely satisfied with either syntax, so at this point I'm merely hoping to start a discussion. 

Thoughts?
=end


-- 
http://bugs.ruby-lang.org/