From: "wardrop (Tom Wardrop)" Date: 2013-04-06T08:58:09+09:00 Subject: [ruby-core:54041] [ruby-trunk - Feature #8191] Short-hand syntax for duck-typing Issue #8191 has been updated by wardrop (Tom Wardrop). To clarify, there's no single official proposal here. My original post and subsequents posts touch on various syntactical and behavioural possibilities. Ignoring syntax for the moment, there seems to be 3 potential behaviours we could implement: # Abort on nil, or on falsey # Abort when #respond_to? is false # Abort on NoMethodError I think I'm starting to feel that #respond_to? is too fragile. You really don't know if an object will respond to anything until it's called. Hence option's 1 and 3 seem more practical, though they're quite different. We may even find them to be complimentary and decide to implement both. user && .profile && .name In the previous example, we only want to call the next method if the previous expression returned truthy. We want to know about any NoMethodError's in this case, as if #profile returns truthy, but it doesn't respond to the expected method, there's a problem with the code. ...I have to go for the moment, but the question mark syntax is for cases where you know very little about the object(s) you're dealing with, or the environment your code is run in (e.g. templates). I feel I need to give better use cases for this particular set of use cases though. ---------------------------------------- Feature #8191: Short-hand syntax for duck-typing https://bugs.ruby-lang.org/issues/8191#change-38275 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/