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


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


=begin
In my example using (({user.profile??.website??.thumbnail})), it assumes that if the (({website})) method exists, then whatever it returns will have a (({thumbnail})) method. It'd probably make more sense to add the double question marks to (({thumbnail})) as well: (({user.profile??.website??.thumbnail??})). Depends on your API of course.

@davidderyldowney, ideally, a single question mark would probably make that clearer, but alas, a single question mark serves another purpose. The question mark prefix is always an option though as well, e.g.

    user.?profile.?website.?thumbnail

But that seems uglier and even more confusing to me. The other option is to go back to the implicit "rescue NoMethodError", (({missing})) is also a potential keyword candidate e.g.

    user.profile.website.thumbnail missing nil

I still prefer the double question mark syntax though. Remember, you're not going to see this plastered everywhere. You'll only see it in place of uglier code such as:

    user && user.profile && user.profile.website && user.profile.website.thumbnail
    
    user.profile.website.thumbnail rescue nil

Even the above two examples are not as robust as this proposal. The first assumes that if (({user})) is truthy, it'll respond to (({profile})) and so on, while the second example assumes that the only possible exception that could be raised in a NoMethodError caused by the method chain itself, potentially suppressing all kinds of valid exceptions. The equivalent long-hand syntax for my proposed short-hand syntax is in fact:

    if user.respond_to? :profile  && user.profile.respond_to? :website && user.profile.website.respond_to? :thumbnail
      user.profile.website.thumbnail
    end

Even that syntax isn't a perfect match, as if for example the (({user})) method is process-heavy, calling it 4 times is going to be slow. So in fact, here's what you'd have to do to achieve the same results as  (({user.profile??.website??.thumbnail??})):

    if (user_obj = user).respond_to?(:profile) && (profile_obj = user_obj.profile).respond_to?(:website) && (website_obj = profile_obj.website).respond_to?(:thumbnail)
      website_obj.thumbnail
    end

My point I guess, is that there's a clear benefit to be had here.
=end
----------------------------------------
Feature #8191: Short-hand syntax for duck-typing
https://bugs.ruby-lang.org/issues/8191#change-38131

Author: wardrop (Tom Wardrop)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
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/