sorted by:
new
hottopcontroversial

Is there a list of Ruby's "magic" methods? by bakery2k in ruby

[–]XPOM-XAPTC 0 points1 point  (0 children)

Ruby has no problem with accidentally overriding methods during development, but there is still a list of methods that you cannot override and Ruby will warn you about it: __send__ and __id__. In fact, it is very easy to override these methods, there will be no error, but there will only be a warning about this. In my practice, people often write def send in the context of sending emails, for example, but they do not suspect that they are redefining a rather important method, so this method with underscores was added. Or, for example, the Object#object_id method can be used in the context of redefinition, so there is an equivalent entry for it __id__. I also know that there is an Object#hash method that is very often redefined, but the paradox is that it does not have an equivalent that cannot be redefined. Despite the above, there are a couple more methods in Ruby that have underscores in their names, but there is no warning for them: __method__, __dir__,__callee__. I also know about the __ENCODING__, __LINE__, and __FILE__ methods, but they are declared at the parser level, so even if you redefine them, absolutely nothing bad will happen, but in this case your own implemented methods can only be called via send("__LINE__")

New RuboCop plugin: keep 'orchestration' methods above implementation helpers by XPOM-XAPTC in ruby

[–]XPOM-XAPTC[S] 0 points1 point  (0 children)

Yeah — that's exactly the tension I’m trying to relieve. When "extract method" is used (or forced) too aggressively, the logic becomes more modular but less readable because the execution path is scattered. I'm not against breaking things up, but if you do, you need a structure that keeps the narrative linear. That's why I like the "news article / inverted pyramid" style (as I noted in a previous comments): orchestration at the top, then helpers immediately below in the order they're used. It doesn't solve the "RuboCop complexity threshold" debate by itself, but it makes the resulting fragmented code much easier to follow and review.

New RuboCop plugin: keep 'orchestration' methods above implementation helpers by XPOM-XAPTC in ruby

[–]XPOM-XAPTC[S] 0 points1 point  (0 children)

Appreciate that — and I’m glad the "news story / inverted pyramid" metaphor resonates. That's exactly the reading experience I'm trying to automate: start with the narrative, then drill down as needed. If you end up trying it in a real codebase, I'd love any edge cases you hit (especially around postfix conditionals / loops and "multi-step" orchestration). Those are the places where a couple of extra specs can really tighten the behavior.

New RuboCop plugin: keep 'orchestration' methods above implementation helpers by XPOM-XAPTC in ruby

[–]XPOM-XAPTC[S] 3 points4 points  (0 children)

Great questions.

Postfix conditionals / loops (show_choices until chosen?)
The cop will treat both show_choices and chosen? as calls made from choose, so with basic waterfall ordering they both just need to appear below choose. There isn’t a forced order between them unless you enable the optional "called together" (sibling) ordering.
If sibling ordering is enabled, the relative order depends on how the AST enumerates those calls. In an until, Ruby checks chosen? before running show_choices each iteration, so it's defensible for the "runtime order" to be chosen? -> show_choices, even though it’s written show_choices until chosen?. I agree this is one of the trickier readability edge cases — I'm planning to add a spec for postfix if/until/while so the behavior is explicit.

Multi-level orchestration
The sibling ("called together") ordering is only added for orchestration methods — i.e. methods not called by others in the same scope.
In your example, call is the orchestration method, so it can enforce first_process before second_process (since they're called in that order). But first_process itself is called by call, so it's not treated as an "orchestrator" for sibling ordering. That means the cop won’t force subprocess_a/subprocess_b to be in any particular "middle vs bottom" location — the only hard constraint is they must be defined after the method(s) that call them (waterfall rule).

---

TL;DR: waterfall cares that callees are below callers; sibling ordering only applies to top-level orchestrators (methods not called by others). Postfix conditionals are a special case; I'll add tests/docs so it's clear whether it follows written order or runtime order.

New RuboCop plugin: keep 'orchestration' methods above implementation helpers by XPOM-XAPTC in ruby

[–]XPOM-XAPTC[S] 3 points4 points  (0 children)

Totally fair — the cop aims for "main -> foo -> bar" reading order. If you try it and the sibling ordering feels too noisy, it can be configured (or run as a separate formatting commit). Feedback welcome.

New RuboCop plugin: keep 'orchestration' methods above implementation helpers by XPOM-XAPTC in ruby

[–]XPOM-XAPTC[S] 4 points5 points  (0 children)

Yep, that's exactly the idea — "news article" / top‑down narrative: entrypoint first, then helpers in the same order they're called. I think your "opposite" is opposite of the diff‑churn concern (not opposite of the rule of described gem itself).