Swift for Rubyists: Optionals

Swift for Rubyists: Optionals(nottombrown.com)

17 points by nottombrown 11 years ago | 9 comments

anorwell 11 years ago |

You don't touch on the fact that options act can act Monads (i.e., that you can invoke an operation on the inner value, conditional on whether or not the optional value is present). For example, an optional user translates naturally to an optional user.name.

I haven't tried swift, and it's not obvious to me from the swift documentation if their options support arbitrary transformations, or just method chaining. In ruby (with ActiveSupport) this is the difference between:

      might_be_nil.try(:method)

and

      might_be_nil.try { |value| my_function(value) }

The latter is more general and useful than the former.

nottombrown 11 years ago | |

Here's the source of try from active_support

    def try(*a, &b)
      if a.empty? && block_given?
        yield self
      else
        public_send(*a, &b) if respond_to?(a.first)
      end
    end

https://github.com/rails/rails/blob/d68419a88e424e588c2d8dec...

Should be easy to do the same in swift. Let me take a stab at it.

nottombrown 11 years ago | |

Here's an implementation of the latter try operator in swift.

    extension Optional {
        func try<U>(f: (T) -> U) -> Optional<U> {
            if let unwrapped = self {
                return f(unwrapped)
            } else {
                return nil
            }
        }
    }

You can see how to use it in this gist:

https://gist.github.com/nottombrown/c6585cad9588a9dc5383

krisdol 11 years ago |

Is this different than setting a default value of nil to user?

    def print_favorite_dinosaur(user: nil)

    def print_favorite_dinosaur(user = nil)

Or is it effectively a different syntax for the same concept?

In either language, you still signal that the argument could be nil, and you still have to guard against it. Or so I think

nottombrown 11 years ago | |

In Swift, you have to signal and guard against the nil.

In ruby, you choose whether to signal and you choose whether to guard. Here are some ruby examples that may be more clear:

Does not signal

    user = User.find_by_favorite_dinosaur("Dromiceiomimus")

Does not guard

    def print_favorite_dinosaur(user)
        p "User's favorite dinosaur is #{user.dino})"
    end

Signals and guards

    def print_favorite_dinosaur(user)
        if user
            p "User's favorite dinosaur is #{user.dino})"
        else
            p "No user. (Let's assume she likes T-rexs)"
        end
    end

    possible_user = User.find_by_favorite_dinosaur("Dromiceiomimus")

    print_favorite_dinosaur(possible_user)

krisdol 11 years ago | | |

Thanks, I didn't know that swift requires the optional to be guarded against.

nottombrown 11 years ago |

Author here. Let me know your thoughts, concerns, and favorite dinosaur.

notduncansmith 11 years ago | |

Nothing to do with the article, but I think it's interesting to see someone else with the "not#{first_name}#{last_name}" pattern. I didn't know that was a common thing.

nottombrown 11 years ago | | |

Totally trending. All of us Smiths, Browns, and Johnsons have to do something to claim our handles.

http://names.mongabay.com/most_common_surnames.htm

extension Optional { func try<U>(f: (T) -> U) -> Optional<U> { if let unwrapped = self { return f(unwrapped) } else { return nil } } }

def print_favorite_dinosaur(user) if user p "User's favorite dinosaur is #{user.dino})" else p "No user. (Let's assume she likes T-rexs)" end end possible_user = User.find_by_favorite_dinosaur("Dromiceiomimus") print_favorite_dinosaur(possible_user)