1. 11
  1.  

  2. 4

    it’s also called the Null Propagation operator or the ?. operator, which will be new in C# 6.0

    1. 6

      I have some suggestions for alternate names:

      • demeter violation operator
      • billion-dollar operator [cf Tony Hoare quote]
      • what’s a null object operator
      • certainty operator [going for an anti-maybe vibe]
      • anti-maintenance operator
      • makework operator [eg. writing code for job security]
      • liar loan operator
      • typedangerous operator
      • invalid data propagation operator
      • error operator
      1. 4

        I’d like to add some ideas:

        • yolo operator
        • mini-Maybe operator
        • Schrödinger operator (your data may or may not be there, but we’ve abstracted that fact away)
      2. 2

        ruby is dynamic enough that I wonder why they didn’t just add this as a library? I wrote a wrapper class that does safe navigation in python as a joke a few years ago:

        https://gist.github.com/shanemhansen/4675780

        1. 2
          1. 1

            Well, ActiveSupport has try! and Avdi Grimm’s Naught library has a Maybe(thing) . So it’s not like there aren’t approaches to doing this already in Ruby, but this is far terser.

            To add to the alternate name suggestions above, I heard somebody calling it the “claw of demeter operator” which I thought was funny.

            My personal take on the operator: it’s going to make novice code a lot uglier, but it could be handy when used sparingly. For the most part I see it as a code smell, but that pattern is not going away so I guess embracing it in the language is alright.

          2. 1

            It would be nice to be able to override the behavior of the operator…

            1. 1

              Could you give a scenario where you’d like to do that? It seems to me the only sane implemenation of this in Ruby would be:

              class BasicObject
                def ?
                  self
                end
              end
              

              The only other thing I can imagine doing is monkeypatching nil with some kind of context-specific behavior, which seems dangerously magical even for Ruby.

              1. 1

                I feel that it could be useful in terms of implementing “container objects” (like an Either monad) more pleasantly. At present, gems like mine (forked from possibly) rely on rather gross method_missing metaprogramming, whereas being able to define a .? behavior would make it more obvious when you’re using the container object. Consider:

                def thing_that_can_fail
                  Success.new(thing)
                rescue
                  Failure.new(thing)
                end
                
                result = thing_that_can_fail
                

                If you could define .? on these objects or a superclass, you can skip tons of repetitive checking as well as non-introspectable metaprogramming.

            2. 1

              Usually when I have something that could be null, I find myself using a structure of doing something when null and another when not. I am not sure this operator is really that useful.

              1. 3

                It allows quick navigation for trees where an element close to the root is optional.

                self.?children.?first.?name
                

                That’s obviously a contrived example, but it’s not unusual, especially in rendering code.

                Objective-C and Groovy have similar behaviors.