Swift for Rubyists: Optionals
nottombrown.com
Swift for Rubyists: Optionals
1–10 of 11 posts
Re: Swift for Rubyists: Optionals
#2Author here. Let me know your thoughts, concerns, and favorite dinosaur.
Re: Swift for Rubyists: Optionals
#3You 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)
might_be_nil.try { |value| my_function(value) }
Re: Swift for Rubyists: Optionals
#4[deleted]
Re: Swift for Rubyists: Optionals
#5Is this different than setting a default value of nil to user?
def print_favorite_dinosaur(user: nil) def print_favorite_dinosaur(user = nil)
In either language, you still signal that the argument could be nil, and you still have to guard against it. Or so I think
Re: Swift for Rubyists: Optionals
#6You 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 ru…
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
Should be easy to do the same in swift. Let me take a stab at it.
Re: Swift for Rubyists: Optionals
#7Is this different than setting a default value of nil to user? def print_favorite_dinosaur(user: nil) or 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
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")
def print_favorite_dinosaur(user)
p "User's favorite dinosaur is #{user.dino})"
end
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)Re: Swift for Rubyists: Optionals
#8Author here. Let me know your thoughts, concerns, and favorite dinosaur.
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.
Re: Swift for Rubyists: Optionals
#9Author here. Let me know your thoughts, concerns, and favorite dinosaur.
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.
Totally trending. All of us Smiths, Browns, and Johnsons have to do something to claim our handles.
Re: Swift for Rubyists: Optionals
#10You 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 ru…
Here's an implementation of the latter try operator in swift.
extension Optional {
func try(f: (T) -> U) -> Optional {
if let unwrapped = self {
return f(unwrapped)
} else {
return nil
}
}
}