[ruby-core:53948] Re: [ruby-trunk - Feature #8191] Short-hand syntax for duck-typing

On Wed, 2013-04-03 at 14:47 +0900, wardrop (Tom Wardrop) wrote:
> Issue #8191 has been updated by wardrop (Tom Wardrop).
> 
> 
> I don't mind that. In fact, it gives me an idea for something even more generic, and with more potential application:
> 
>     user && .profile && .website && .thumbnail

I don't see this mentioned upthread anywhere, but as far as I can tell
this proposal is basically covered by
https://github.com/raganwald/andand.git .  Objections to this are
objections to the Maybe monad.  Given that, if we're going for new
syntax, for the #nil? case I quite like the look of:

  user.&&.profile.&&.website.&&.thumbnail

but making '&&' a valid method name might be a trifle difficult to get
right...

-- 
Alex

> 
> Ruby could implement this as new syntactic rule. A dot operator at the beginning of an expression, proceeded by a valid method name, would be called on the result of the last expression in the current scope. Technically, it would allow this:
> 
>     lowercase = 'string'
>     uppercase = .upcase
> 
> That's pretty useless, but the point is that the syntax would be generic and unassuming, allowing for all kinds of interesting uses. Here's a random example. Not saying it's the best way to do this, but just demonstrating the potential:
> 
>     catch(:pass) do
>       # Do some stuff here
>     end
>     
>     puts "The block was passed" if .nil?
> 
> In this case, the last expression in the scope was the return value of (({catch})). That's what #nil? ends up being called on.
> 
> Unfortunately, it doesn't completely solve the issues raised. For example, it does nothing for the use case ({!obj || obj.empty?})) which will still bomb if ((|obj|)) doesn't respond to (({empty?})}.  The double-question mark would still solve this issue (({!obj || obj.empty???})), but I still like the implied method target idea, but for different reasons.
> ----------------------------------------
> Feature #8191: Short-hand syntax for duck-typing
> https://bugs.ruby-lang.org/issues/8191#change-38152
> 
> 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
> 
>