1. 2

    FWIW the author discussed this idea on Twitter with Matz:

    Nick Sutterer (@apotonick): Hi @yukihiro_matz - what do you think about this? https://apotonick.wordpress.com/2018/01/17/dear-ruby-1-what-about-arguments-when-inheriting/ (I’m probably not the first one with this idea?!)

    Yukihiro Matsumoto (@yukihiro_matz): @apotonick How about generating a class to be a superclass?

    class Foo<Bar(args) … end

    where Bar() is a method that returns a class.

    Nick Sutterer (@apotonick): @yukihiro_matz Yes, that’s the current approach in many gems. However, this implies some meta programming and an anonymous class, whereas the extended ::included signature would be consistent and in-line with #initialize, right? Thanks Matz!

    Yukihiro Matsumoto (@yukihiro_matz): @apotonick I am afraid that I don’t share that “consistent and in-line with” feeling.

    Nick Sutterer (@apotonick): @yukihiro_matz 😬 It’s “create an intermediate, anonymous class between A and subclass B” vs. “allow passing explicit arguments and set variables on B after B is inherited, the way you do it when creating object instances”

    Nick Sutterer (@apotonick): @yukihiro_matz Ok, let’s forget the “consistent” argument. What’s better: passing arguments to a method, or having to create a temporary anonymous class to transport those arguments?

    Yukihiro Matsumoto (@yukihiro_matz): @apotonick Yours consumes less memory. That is good. But it may make the language more complex.

    Besides that, considering potential code breakage, I cannot simply say yours is “better”.

    Nick Sutterer (@apotonick): @yukihiro_matz Thanks, agreeing. ✌️My idea introduces a syntactical change, true. Does that make the language more complex? Yes.

    Creating an intermediate class instead: makes the USE of the language more complex.

    Could there be any incompat, though? 🤔🤓🧐

    Yukihiro Matsumoto (@yukihiro_matz): @apotonick Your particular example

    class Memo::Render < Render, engine: Render::JSON … end

    does not conflict with existing syntax (due to the comma after ‘Render’), but I am not positive with a comma here because it reminds me multiple inheritance.

    Nick Sutterer (@apotonick): @yukihiro_matz Many thanks, I will elaborate more on this idea and talk to other gem authors about whether or not it would be cool to have that, etc. So there is no other proposal for this, yet? Haha, maybe I’m crazy 🤪 thanks!

    1. 2

      Here’s the approach Matz is referring to: https://gist.github.com/bkudria/82e3721d4ec2b62a2a3d95050e964d84

    1. 1

      I’ve found Dark Reader to be very helpful and rarely broken.

      1. 1

        hmm, just tried it and it inverted the already dark Ars Technica into a bright color scheme. so I could switch Ars back, or disable the extension, etc., but it feels kind of silly. But I’ll consider it some more.

      1. 5

        If you want to explore the reality behind your last paragraph, you can consider reading “Zen Mind,Beginner’s Mind” by Shunryu Suzuki: https://amazon.com/Zen-Mind-Beginners-Shunryu-Suzuki-ebook/dp/B00I8USOM0

        1. 2

          I was given an interesting variation on FizzBuzz recently.

          The first half of the question was a stage, a slightly extended version of the problem: Fizz when N % 0 == 5, or when N in base 10 contains the digit 5. Likewise Buzz on N % 7 == 0, or contains the digit 7 – and the expected confluence for both.

          The second half of the question was to implement a test-case generator - a function to enumerate the smallest number for each of the 16 possible combinations of properties. 16 could theoretically be hard-coded, but if one were to add a third condition (i.e divisible by or containing 3) the number of cases becomes infeasible to enumerate manually.

          1. 2

            This is a very short, but excellent comparison between “Design Patterns” and Design Patterns: http://perl.plover.com/yak/design/

            1. 1

              Peter Norvig also has a great presentation on implementing patterns in dynamic languages (specifically Dylan): http://www.norvig.com/design-patterns/design-patterns.pdf