2 ms·

I'm not sure if you are arguing with me or with Rails. Rails includes the #returning method. If you don't like using it you are entitled to your opinion. I won'

I'm not sure if you are arguing with me or with Rails. Rails includes the #returning method. If you don't like using it you are entitled to your opinion. I won't argue with you, because that is not what this post is really about. I encountered bugs like forgetting to return the intialized object from a method as well as assigning to the parameter of a return invocation a number of times when working with a large Rails code base. But if you have never encountered it, you need never use #returning in any of its forms. So really, I'm not arguing with you. Different people, different experiences, different approaches to code. I like #returning, I like #let, I like a lot of things that impose block structure on code. Others do things differently with my blessing.

codyrobbins 17y ago
Yeah, I know I don't have to use it. I just think the style it introduces is more abstruse overall than the problem it's solving. To answer your question, I'm mostly arguing with Rails, not you. Obviously, if it's useful to people they'll use it and who am I to declare by fiat that something's not useful to somebody else? But just because some level of personal preference is involved doesn't mean we can't try to talk about something on the basis of its objective merits. But I'm often (usually?) wrong — I was just putting in my two cents for the sake of discussion =)
- raganwald 17y ago
  Well then, if you want to talk, I'd say this... (elided). No, scratch that, instead I'll say this: I don't buy the argument that #returning, or SymbolToProc, or any of the other myriad (and often irritating) little idiomatic extensions to Ruby make code less complicated and more difficult to read. It's an old, old argument and tiresome to rehash, but ultimately it's a mistake to make things easier to read for someone who doesn't know the idioms at the expense of making things easier to read for somone who does know the idioms. If you feel the idiom doesn't add value, that's one thing. But I have trouble with the idea that #returning is harder to read. I personally find it easier to read because it is so obvious what is going on.
  - codyrobbins 17y ago
    Isn't it implied and understood that I can only speak for myself and from my own perspective? I think my post was littered liberally enough with words like 'personally' and 'I feel' that it's understood I'm not trying to speak in absolutes. So, would you rather I didn't raise any questions about the relative merits of the code simply because there may be people who find it useful? I'm certainly not arguing that no one will find it useful, I'm simply saying that I don't like it and giving the reasons why I think so. If you didn't want people to discuss the relative merits of the code, why did you post it? EDIT: Ah, you elided what the above is a rebuttal of, which is good because that brings the discussion back to the actual code in question. There are a ton of little idiomatic extensions to Ruby that are immensely useful, SymbolToProc being a very good example. The presence of so many of them is one of the great things about Rails. So, I'm not arguing against such things as a whole, as you imply I am. I'm simply saying that #returning in particular is one that I have problems with. Nor am I saying that making things less readable for the uninitiated is a sufficient motivation to bar use of such things. However, this particular idiom gives you so little that I feel what you gain from it does not outweigh the cost of introducing it. So, I do feel that the idiom doesn't add any value, and for that reason there is a cost associated with its use. It doesn't save you any code, and it's more complicated than the code it replaces, which is why I am puzzled that you find it easier to understand. It makes things wordier with a block invocation when a simple assignment will suffice. Ostensibly, assignment is a much 'lower level' mechanism than invoking a method with a block. I readily admit, though, that if you find it easier to read then there's no argument I can make, because it works for you. Similarly, though, I can state that it is not easier to read for me. So, I guess we just have to agree to disagree on the basis that our brains work differently =)
    - deleted 17y ago
      [deleted]
    - raganwald 17y ago
      > I think my post was littered liberally enough with words like 'personally' and 'I feel' that it's understood I'm not trying to speak in absolutes. It was understood right up to the words "no discernable benefit" that closed the original comment :-) But any ways, of course I expect lively discussion about the post, just as you must expect responses to your comment. So to get back to the actual subject of the #returning idiom... I think your comments apply to a lot of Ruby idioms as distinguished from abstractions. For example, is `customers.map(&:name)` a win over `customers.map { |c| c.name }`? Is `customers.first.try(&:name)` a win over `customers.first && customers.first.name`? Brevity alone is not enough reason to prefer these idioms, IMO. You have to buy that they express the intention more clearly, making them more readable, not less readable in your eyes. Some people just don't see such idioms as making the code more precise, more communicative. If you're in that camp with respect to #returning, you are not alone by a long shot.

codyrobbins 17y ago

Yeah, I know I don't have to use it. I just think the style it introduces is more abstruse overall than the problem it's solving. To answer your question, I'm mostly arguing with Rails, not you. Obviously, if it's useful to people they'll use it and who am I to declare by fiat that something's not useful to somebody else? But just because some level of personal preference is involved doesn't mean we can't try to talk about something on the basis of its objective merits. But I'm often (usually?) wrong — I was just putting in my two cents for the sake of discussion =)

raganwald 17y ago
Well then, if you want to talk, I'd say this... (elided). No, scratch that, instead I'll say this: I don't buy the argument that #returning, or SymbolToProc, or any of the other myriad (and often irritating) little idiomatic extensions to Ruby make code less complicated and more difficult to read. It's an old, old argument and tiresome to rehash, but ultimately it's a mistake to make things easier to read for someone who doesn't know the idioms at the expense of making things easier to read for somone who does know the idioms. If you feel the idiom doesn't add value, that's one thing. But I have trouble with the idea that #returning is harder to read. I personally find it easier to read because it is so obvious what is going on.
- codyrobbins 17y ago
  Isn't it implied and understood that I can only speak for myself and from my own perspective? I think my post was littered liberally enough with words like 'personally' and 'I feel' that it's understood I'm not trying to speak in absolutes. So, would you rather I didn't raise any questions about the relative merits of the code simply because there may be people who find it useful? I'm certainly not arguing that no one will find it useful, I'm simply saying that I don't like it and giving the reasons why I think so. If you didn't want people to discuss the relative merits of the code, why did you post it? EDIT: Ah, you elided what the above is a rebuttal of, which is good because that brings the discussion back to the actual code in question. There are a ton of little idiomatic extensions to Ruby that are immensely useful, SymbolToProc being a very good example. The presence of so many of them is one of the great things about Rails. So, I'm not arguing against such things as a whole, as you imply I am. I'm simply saying that #returning in particular is one that I have problems with. Nor am I saying that making things less readable for the uninitiated is a sufficient motivation to bar use of such things. However, this particular idiom gives you so little that I feel what you gain from it does not outweigh the cost of introducing it. So, I do feel that the idiom doesn't add any value, and for that reason there is a cost associated with its use. It doesn't save you any code, and it's more complicated than the code it replaces, which is why I am puzzled that you find it easier to understand. It makes things wordier with a block invocation when a simple assignment will suffice. Ostensibly, assignment is a much 'lower level' mechanism than invoking a method with a block. I readily admit, though, that if you find it easier to read then there's no argument I can make, because it works for you. Similarly, though, I can state that it is not easier to read for me. So, I guess we just have to agree to disagree on the basis that our brains work differently =)
  - deleted 17y ago
    [deleted]
  - raganwald 17y ago
    > I think my post was littered liberally enough with words like 'personally' and 'I feel' that it's understood I'm not trying to speak in absolutes. It was understood right up to the words "no discernable benefit" that closed the original comment :-) But any ways, of course I expect lively discussion about the post, just as you must expect responses to your comment. So to get back to the actual subject of the #returning idiom... I think your comments apply to a lot of Ruby idioms as distinguished from abstractions. For example, is `customers.map(&:name)` a win over `customers.map { |c| c.name }`? Is `customers.first.try(&:name)` a win over `customers.first && customers.first.name`? Brevity alone is not enough reason to prefer these idioms, IMO. You have to buy that they express the intention more clearly, making them more readable, not less readable in your eyes. Some people just don't see such idioms as making the code more precise, more communicative. If you're in that camp with respect to #returning, you are not alone by a long shot.