Marc-André Lafortune

@bbatsov did you get a chance to read this?

@pirj: Your example is error prone: ``` class Anything include CLISpecHelper end Anything.new.environment_specs_coefficients # => Error, no `super` method ``` > both extend self and module_function have their usages. Which...

Sorry, forgot that they would be private. So a method from `Anything` calling `environment_specs_coefficients` would trigger an error. ```ruby class Anything include CLISpecHelper def foo environment_specs_coefficients end end Anything.new.foo #...

> Again - I'll clarify the this guideline about `module_function` was always intended for the case of a module with call functions that it's meant to be used directly. It's...

I imagine that implementation methods starting on a newline is intentional, probably to make it easier to grep for them; is there a way to keep that?

> requiring stuff outside of the top-level scope. I feel this is a very different issue (and I'd love to argue in favor of that if you want to open...

> I clearly understand that assign_kids_to_school(john, mary, penny, vicky, school: best_school_in_the_world) is better, The fact that is it so much better is the reason that `def assign_kids_to_school(*kids, school)` should be...

I don't like the current "Optional Arguments" section. 1) It is contradicted by the later rule you point out 2) "Ruby has some unexpected results when calling methods that have...

Can we make is a hard recommendation, and remove the "Optional arguments" then? 😅 Or at least remove the "Ruby has some unexpected results when calling methods that have optional...

> I'm not too fond of keyword arguments Sorry to hear how much we disagree on this > forwarding deficiencies [with `...`] Glad to see we agree on this, for...