Shouldn't the `#descendants` method be the reverse of `#ancestors`? `#ancestors` traverses up both class hierarchies and module inclusion chains. That tells me both `Module#descendants` and `Class#descendants` will make sense, and ...dgutov (Dmitry Gutov)
This is not as bad as the "pipeline operator" (which didn't do what its name said), but still, why add this? It's not like the new syntax makes anything possible that a simple assignment does not. The "method chains" example is per...dgutov (Dmitry Gutov)
Matz: Ruby being a "Lisp-2" means that the pipeline operator couldn't be implemented like a "normal" operator (all of them being translated to methods on Object or etc), but it could be implemented on the parser level, like almost all...dgutov (Dmitry Gutov)
"I don't have to use it" doesn't work in the real world where you have projects with multiple contributors, dependencies and multi-year history. This new "feature" does not add *anything* except a new way to write a method call, and w...dgutov (Dmitry Gutov)
This is what happens when one syntactic sugar(*) collides with another. (*) `a.map { |x,| x }` being a shorthand for `a.map { |(x)| x }` , and sometimes not, depending on the runtime values. Neither of these are good, IMO (one for ...dgutov (Dmitry Gutov)
> we haven't reached consensus to remove double colons for method calls from the language. That's what this issue is about, isn't it? > ... I agree. But deprecating it would already be beneficial. > we have convention of Array c...dgutov (Dmitry Gutov)
+1 "::" method call syntax has no advantages over ".", and it should be relatively simple to search through any codebase and convert the instances of using the former into the latter automatically.dgutov (Dmitry Gutov)
dgutov (Dmitry Gutov)10:46 PM Ruby Feature #14394: Class.descendants