1. 26

edit: link should point to http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf which I learnt about after creating this submission.

  1.  

  2. 5

    According to the author on HN, the link should be updated to http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf

    1. 1

      Really sorry for that. I was trying to edit the submission now, but I cannot change the url as I’m not a moderator.

      1. 4

        lobsters feature proposal: bat signal to gain a moderator’s attention

        1. 2

          Please feel free to use the message feature to get in touch with me or jcs.

          1. 4

            bat signal would add a lovely touch of whimsy though :) ?

    2. 3

      The idea seems similar to Rust, actually:

      • Mutable objects may be moved from one guild to another (similar to the Send trait in Rust)
      • Immutable objects may be shared between guilds (similar to the Sync trait in Rust)
      • Special data structures can be made to allow mutable sharing. If something fails, you only need to check the special data structure (the innards of the data structures would be similar to unsafe in Rust)

      Sounds like an interesting proposal. I haven’t done a ton of Ruby programming, so I don’t know if this makes sense for the broader ecosystem, but it’s nice to see this effort happening.

      1. 2

        What is nice about this approach is that you can bolt it onto ruby without affecting any existing ruby code. IMO, the real question is going to be if library authors are willing to make the changes needed to support this. Any library that uses mutable global state for configuration appears to have issues under this pattern.

        1. 2

          Well, I’m not sure what the exact semantics up a guild are (as the implementation, twitter has it, lives on the authors notebook), but the presentation mentions that globals would become guild-global.

          1. 2

            Any library that uses mutable global state for configuration appears to have issues under this pattern.

            I would argue that is an anti-pattern, and I generally would like to see less of that in the ruby ecosystem.

            1. 1

              While I fully agree with you, it’s still something that we need to contend with if this proposal moves forward.

            2. 2

              Any library that uses mutable global state for configuration appears to have issues under this pattern.

              The question is which type of mutable global state are they using? A lot of the hair I’ve lost from using these sorts of libraries (i.e. global config data) use either class variables or class-instance variables. The most common trouble I’ve had resulting from that is when configuration is treated not as a set of defaults for objects you construct, but as the only set of settings for the library.

              For instance, three-of-every-four bog-standard API clients seem to want me to configure them with a single API key (or logger, or timeout, or whatever). Then when I call Client.new it automatically uses that API key, logger, and other settings. What if I have two accounts or sets of credentials for different purposes? Or I want one part of my code to log to one place when using a client, and another part of my code should log some other way?

              It’s fairly easy to patch that sort of behavior, in practice. So instead of this all-too-common situation when you’re locked into your API key confiured at load-time:

              SomeService.configure { |config| config.api_key = "foobar" }
              
              class SomeService::Client
                def initialize
                  @api_key = SomeService.api_key
                end
                # Rest of client functionality.
              end
              

              You just make the api_key optional, using the configured one as the default.

              class SomeService::Client
                def initialize(api_key: SomeService.api_key)
                  @api_key = api_key
                end
                # Rest of client functionality.
              end
              

              Especially if it is done with keyword arguments, it’s also backward-compatible with existing code, even if the existing code already had some funky argument list for initialize with a slurp and a few argument defaults using = signs.