From: "JonRowe (Jon Rowe)" <hello@...>
Date: 2013-04-03T11:49:26+09:00
Subject: [ruby-core:53935] [ruby-trunk - Feature #8191] Short-hand syntax for duck-typing


Issue #8191 has been updated by JonRowe (Jon Rowe).


@wardrop The reason we all love Ruby is because it makes us happy. This suggestion makes me unhappy, so I'm saying so, and I'm attempting to do so constructively. Ruby has an ethos around writing elegant clean code which deserves protection. I think your suggestion will just create more spaghetti code, which we should be keen to avoid.

"Law of Demeter essentially states that method chaining is bad. I personally don't see it's relevance to Ruby." 

Yet obeying the Law of Demeter in your example, user.profile.website.thumbnail, would have meant you wouldn't have this problem. You are attempting to palm off the consequences of your decision to write code in this fashion to the language, rather than refactoring your code to clean it up.

"I don't think it's helpful to discuss programming patterns here." 

It really is, discussing how we write code affects how we make decisions about the language. If you ignore how we actually write code, and how we should be striving to produce better code, then you are ignoring the consequences of your decisions. Requests made to change the language need to be carefully considered to see how they will affect the way we right code. They should have a net positive effect and not just add cruft for the sake of it.

Additionally this feature has already been rejected once, #1122, because:

"Matz first said he hesitated to extend the syntax for this feature. He then said there is no good reason to make this feature built-in;" so this is just a further syntax extension, and there is still no good reason to make this feature built in."

----------------------------------------
Feature #8191: Short-hand syntax for duck-typing
https://bugs.ruby-lang.org/issues/8191#change-38147

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/