3 ms·

Oh so they knew? My understanding is that it's already released, warts and all. Did I misread? So the tradeoff is that the parsing rules of that operator may c

• vidarh 3y ago
  > Oh so they knew? It was an obvious consequence of the grammar rule that was updated. > My understanding is that it's already released, warts and all. Did I misread? It was added on a experimental basis 3.5 years ago, and released in Ruby 3.0.0 in December 2020 (Ruby currently bumps the first decimal every Christmas day, current release series is 3.2, and 3.3.0 is due this Christmas. > So the tradeoff is that the parsing rules of that operator may change in the future? Who would even use it if it could change again? You can safely use it as long as you understand that anything that inside the method body might operate on a whole assignment expression will likely operate on the `def` if applied to an endless method which is almost certainly not what you want, in which case the solution is to either not use an endless def or use parentheses to make your intent clear. IF operating on the `def` expression is what you want, then you either need to avoid end-less def's or enclose the expression in parentheses or your code might break. That is, this is safe (but means different things), as long as "some_expression" is safe to put as the right hand side of an expression (which might take parentheses or not): def foo = (some_expression if bar) (def foo = some_expression) if bar def foo = some_expression This is not: def foo = some_expression if bar I
  • lolc 3y ago
    Thanks for the clarification. The whole thing is pretty far from the principle of least surprise for me. But so is operating on a def. Why would that be allowed if it is likely to change? Oh well, not that I needed more reasons not to use Ruby.
    • vidarh 3y ago
      > But so is operating on a def. A "def" in Ruby is just syntactic sugar for calling the method `define_method(name) <block>`, and so there's no reason you shouldn't be able to operate on a def by Ruby thinking because it's just another form of expression and disallowing it would involve a special rule for a specific situation. You can do the same with classes, modules etc. ("class Foo; end if expression_evaluating_to_false" will not define Foo, same as if you'd wrapped it in "if false ... end). Even more so because a training "if" is just syntactic sugar for "if <condition> then <expression> end" and so given that Ruby made the choice that defining classes and modules and methods is allowed as expressions in conditional blocks, it'd be an odd exception to exclude them from training if's. The Ruby philosophy there is that this is what falls out of the generic rules, so it's allowed, and maybe someone finds a reasonable use for it, or not, but disallowing it for the sake of it doesn't really fit Ruby. > Why would that be allowed if it is likely to change? That isn't likely to change, and it's not a new thing - it's been part of Ruby from the start. Only the precedence is likely to change exactly to bring it closer to the principle of least surprise. You will still be able to write "def foo; end if some_condition" because expectations there (to Ruby programmers anyway) are clear, or "(def foo() = expression) if some_condition". If it happens, any precedence change will be based on what will cause the least surprise if people leave out the parentheses. Almost everything in Ruby can be thought of as a method call or expression - it's our inheritance from Smalltalk, which is perhaps the strongest influence on Ruby. E.g. a "if" or "case" expression also has a return value, just like "class" and "def". There's "special syntax" in terms of parsing, where Ruby's focus has always been "developer happiness" over purity, but extremely little special syntax in terms of semantics.
      • lolc 3y ago
        Tanks for the context, I see what you mean about not disallowing things. I still don't understand why they released the feature if operator precedence around it could still change. But then, I don't understand the need for the feature, nor would I want to conditionally define a method. I realize the older I get, the less I like late binding :-)