Ruby gaining a safe navigation operator: '.?'
bugs.ruby-lang.org
bugs.ruby-lang.org
My argument for this is you should design for the most common use case first, and most commonly people will want '.?' behavior. You can still check explicitly for null in the other cases, or even introduce a more cumbersome non-safe navigation operator. The resulting code will overall need fewer checks, be more readable, you'll have fewer crashes and exceptions, and it will generally do the right thing.
I occasionally write toy languages and this is one behavior I think I got right recently. Along the same lines, but as a more extreme measure, I would argue that invoking a method call on a null object should return null instead of throwing an exception.
My go-to example in favor of the idea would be languages and libraries where 'null' and 'empty list' cause the same behavior in list-processing functions.
if (input.isInvalid()) {
reject()
} else {
accept()
}
The other main complaint is when you have a long string of methods unexpectedly turn out nil at the end, it's a pain to figure out which one it was.
(int)nil == 0nil is a pointer to the value 0, and in C there is only one value that evaluates to a logical false, which is 0. Invoking a method on nil returns 0. This itself alleviates the kind of nil-check-chains discussed in this thread:
[[[user profile] name] isEqualToString:@"Paul"];
[user profile] && [[user profile] name] && [[[user profile] name] isKindOf:NSString] && [[[user profile] name] isEqualToString:@"Paul"];
Our team is split (I don't know how evenly) on whether Obj-C or Swift's behavior is better. There are some staunch defenders of Obj-C's pattern being better.
I personally prefer requiring the programmer to explicitly handle nil/null. I think it improves maintainability, because future developers can see the code is correct, and it protects against changes (ex: you knew nil could never happen when your code was written, but then someone changed it so nil does occur and now your code is broken). It also saves future developers from spending time reasoning about the behavior of the code when nil occurs.
The distinction is between segfault and returning 0 bits, and I'd say that returning 0 bits is generally better, because most of the time, in iOS apps, especially in absence of a "??" operator, it's what you want. For example, in a table view data source you don't have to check if your data array is non-null, just return its count, it'll be 0 if it is.
i.e. Optional monad > return all 0 bits > segfault
Wouldn't you prefer seeing:
foo .? bar . baz .? roo
Why not make the nil check (or error silencing) explicit when it is so cheap to do so?
I think that Javascript's silencing of wrong parameter counts, Perl's (non-strict) allowing string concat, and non-well-founded implicit coercions (i.e: ones that change the semantics of the value) are all terribly horrible.
I believe that those who value convenience over safety deserve neither and will lose both.
The reasons that is defensible in message passing systems is because such systems are basically recapitulations of computer networks, and object nullity is equivalent to a network partition. That's the kind of failure mode that you handle in the policy layer, which is above the runtime layer in an application system just as it would be above the network layer in a distributed system.
<?php
$foo = array();
echo $foo['a']['b']['c']; // not an error d = lambda {|hash,key| Hash.new(&d) }
foo = Hash.new(&d)
p foo['a']['b']['c']
Of course it's likely to blow up in all kinds of ways since anything trying to do "if foo['a']" to check of 'a' is present in foo will break, for example.
echo $foo['a']['b'] ?? 'default_value'; $v = @first($var1, $var2, 'some-default');
foo?.bar?('baz')
int? count = customers?[0]?.Orders?.Count();
Neither Java nor Groovy has the int? declaration shown which enforces the optionality. The C# version looks more versatile.
Back when Groovy was more popular, its backers also discussed a cascading ? on their mailing list but it never happened. If C# had cascading ? then the example above would be
int? count = customers?[0].Orders.Count();
It's frustrating to have such useful features blocked by such seemingly small problems as ambiguous patterns of characters.
int? count = customers?[0]?.Orders?.Count();
Why not just extend fetch or try e.g. -- .try(:profile, :thumbnails, :large)
Also, there your example or using try falls short if the methods require additional arguments to be passed in. "try" already handles this by requiring you to "try" each method.
Of cause there is a very good argument to be had that this pattern also breaks the law of demeter by allowing you to call methods on objects that you don't own a stake in.
So technically you can pass arguments to a try method by doing object.try {|o| o.method(args) }
Not trying to be pedantic, hopefully being helpful.
module Chainable
def chain(*kl)
k = kl.shift
if self.respond_to?(k)
v = self.public_send(k)
else
v = nil
end
return v if kl.empty?
unless v.respond_to? :chain
raise ArgumentError, "can't chain on `#{k.inspect} => #{v.inspect}:#{v.class}`"
end
return v.chain(*kl)
end
end
class Object
include Chainable
endIt being faster has nothing to do with the syntactical appearance of the operator. I think it's more pertinent to ask why does .chain_try or .tries or .fetches need a special operator than whether it's a convenient addition.
And at that point naming it after something that are legal method names would be problematic.
o.chain :foo, [1, 2, 3], :bar, :baz, {key: 'value'}
Also, it shouldn't make any significant performance difference whether this was implemented as a syntactic sugar, an operator or a method (this doesn't mean it won't perform better than my example method).
> Also, it shouldn't make any significant performance difference whether this was implemented as a syntactic sugar, an operator or a method (this doesn't mean it won't perform better than my example method).
It potentially would make a massive difference. Firstly there's a minimum of 5 method calls just in the success-path in your example, plus at least one object creation (constructing a new argument array in the final call), but potentially more. And that's not nearly all.
Method calls in MRI are expensive, even with caching.
Compare that to implementing the vm-level logic which can do the actual method calls and a nil check and branch.
I still don't understand why special syntax is needed for it, though. As far as I understood your arguments, they keep pointing out flaws in my implementation (which is far from optimised). You could mimic its behaviour through C. Could you elaborate more clearly, if I'm misunderstanding something (I do want to understand).
foo‽bar("baz")Using that operator a single time or whatnot seems handy, but chaining it like that just seems like poor practice to me.
In the article the 'problem' code is:
if u && u.profile && u.profile.thumbnails && u.profiles.thumbnails.large
do_something_with(u.profiles.thumbnails.large)
fi
which would be replaced by only asking once.
even worse (although somewhat clearer, perhaps) is what I've occasionally seen:
if u
if u.profile
if u.profile.thumbnails
if u.profile.thumbnails.large
do_something_with(u.profile.thumbnails.large)
end
end
end
end
if u.profile.thumbnails
You can achieve similar effects using only exceptions, but there's a good argument for using exceptions only for exceptional circumstances.
begin
do_something_with(u.profile.thumbnails.large)
rescue NoMethodError #or similar
# oh no!
end
begin
tmp = u.profile.thumbnails.large
rescue
tmp = nil
end
if tmp
do_something(tmp)
end
I may have got details wrong - not being a rubyist, but I think this is the general gist of where a nestable operator makes much much cleaner code, which catches more errors.
As far as I see the proposed version will work equivalent to assigning the result of each method invocation to a temporary, and doing the next check on that, which gets far more ugly if you have to write it out
The whole motivation of the operator is for chaining.
It's essentially syntax sugar to save time when you want to do something iff the whole chain is filled in.
if posts.comments??.likes??
if posts..comments..likes
if posts.?comments.?likes
The name "elvis" was promoted by the then-project manager of Groovy in an attempt to change the origin meaning of "G-Strings", the name for interpolated strings in Groovy. It originally alluded to the item of clothing, but in an attempt to sanitize Groovy's image for marketing, he wanted it to have meant the string on Elvis's guitar, so he created an accompanying fun-name for the null coalescing operator.
Ruby can't use "?." operator.
Can we use ".?" syntax
def foo?
Object.new
end
foo?.class
Edit: with ".?" looks like "foo?.?class"
Edit 2: side note, this would never pass a code review, the expectation of "foo?" is that it returns true/false.
95% of the time, yes. However, the "official" rule is simply that such methods must return a value that can be EVALUATED as true/false. There are plenty of methods in the ruby core/standard library which end in a "?" but do not return true/false, such as:
* File#size (http://ruby-doc.org/core-2.2.3/File.html#method-c-size-3F) returns Integer or nil.
* Integer#nonzero? (http://ruby-doc.org/core-2.2.0/Numeric.html#method-i-nonzero...) returns self or nil.
This misunderstanding of what "?" methods are allowed to return is an ongoing problem in the community, e.g. https://github.com/rails/rails/issues/20110
This means that something like foo.thing?.bar is potentially ambiguous.
>AFAIK the general practice is to use ! for methods that perform a mutation in-place The ! suffix is rather loosely defined as it just means the user should be cautious/the method might have "dangerous"/surprising behavior.
Your description is usually correct but only when a non-suffixed version exists and not even then the behavior has to match your description. There are also a lot unsuffixed mutating methods. See also Kernel#exit vs. Kernel#exit! (immediate exist/exit handlers aren't called) or Tempfile#close vs. Tempfile#close! (close and unlink).
That's not quite the usual statement of the rule: ! is for methods where there exists a "dangerous" version and a "less dangerous" version, to denote the more dangerous version. A common example of that is methods where one version returns a copy of the original object with some modification applied and the other version modifies the original object in place, but IIRCT that's not the only distinction it is used for in the standard library and, more importantly, in-place mutations that aren't paired with a "return-a-modified-copy" method don't get the !.
if u.profiles.thumbnails.large
>> class NilClass
• def foo!
• puts "bar?"
• end
• end
=> :foo!
>> nil.foo!
bar?
[1] https://github.com/rails/docrails/blob/master/activesupport/...
I'd call it marginally convenient, because you have to type less, but it doesn't increase usability, and the readability is pretty much the same (or worse, because someone would have to know NilClass responds to blank?, if they don't they might've expected an empty array, or an empty string).
Also, why does FalseClass respond to blank? with `true`, but not TrueClass (I didn't know it did this for those two until now)? How is false less blank than true?
The entire point behind #blank? is that it provides a cross-class[2] method that works even when the object doesn't exist (and you get nil instead). This was designed for Rails to simplify situations such as the params[3] (parsed URL query string), which might not have a particular value.
# when handling "/action?foo=bar"
params[:foo] # => "bar"
# when handling "/action?foo="
params[:foo] # => ""
# when handling "/action"
params[:foo] # => nil
if params[:foo].blank?
# render a static placeholder (never looks at params)
else
# render Foo's markup, using the value in params[:foo]
end
> why does FalseClass respond to blank? with `true`, but not TrueClass
That's a good question. I would have assumed both true and false as not-blank (#blank? => false), as those could both be entered (#present?) values. I suspect it's related to HTML forms only including successful controls[4] in the query string.
[1] https://github.com/rails/docrails/blob/master/activesupport/...
[2] see: duck-typing
[3] http://api.rubyonrails.org/classes/ActionController/Paramete...
[4] http://www.w3.org/TR/html401/interact/forms.html#h-17.13.3.2
> I suspect it's related to HTML forms only including successful controls
Yeah, this is a good point, since an unchecked checkbox isn't transmitted in a standard HTML form, but Rails does add a hidden input element with the value false; so I guess #blank? does somewhat increase readability here, but this could've and should've been fixed in a better way (a few ideas come to mind).
Don't get me wrong, I probably used #blank? (and might in the future) just for the sake of convenience. However, it makes me feel guilty when I do, because it could subtly introduce and hide bugs due to lack of more adequate checks.
Nils will get into data structures and figuring out when and where they got there will become more work. You'd end up writing a lot more logic testing for nil and throwing an exception when it's found, to avoid the nil propagating further.
As for why this is a common problem, "u.profiles.thumbnails.large" is is probably a chain of Rails/ActiveRecord model associations[1], which generally map to table rows . If there the "profiles" table doesn't have any rows "WHERE profiles.user_id = users.id", then ActiveRecord will leave a nil[2] (or empty array) in user.profiles. This is true for all foreign key relationships, so you often end up having to do something to protect against null values (no rows) every time you move between models.
Sometimes it is possible to work around this by always creating the associated model when the parent object is created, that only works in a few cases. Note: I recommend against doing tricks to auto-build the associated model on first access: that kind of "clever" solution can lead to confusing bugs later on. (I learned that one the hard way)
[1] http://guides.rubyonrails.org/association_basics.html
[2] ibid, 4.1.1.1 "The association method returns the associated object, if any. If no associated object is found, it returns nil."
Again excuse my ignorance of the subject and technical details in Ruby.
"nil" in Ruby is an instance of NilClass. NilClass has a few methods, but e.g. "thumbnail" is not amongst them, so Ruby looks for a "method_missing" method, doesn't find that either, and then throws an exception, just as if you'd called another non-existent method.
To answer a question you didn't ask, though, you can easily write classes to wrap your objects to get pretty much the effect you are asking about. E.g.:
class Maybe
attr_reader :value
def initialize value
@value = value
end
def method_missing *args
return self if @value.nil?
Maybe.new(@value.send(*args))
end
end
p Maybe.new(nil).i.can.call.anything.without.exceptions
p Maybe.new("Hello foo").gsub("foo","world").value
The second will print "Hello world", as "gsub" will be called on "Hello foo" since the "Maybe" has a non-nil value.
There are any number of implementations of helper classes like this for Ruby, with various levels of popularity. The benefit of course is that you can easily customize the behaviour for your specific needs (e.g. you could create one that will return a default value instead of nil, or you can create one that short-circuits on other values than nil, or any number of alternatives)
The advantage of introducing .? as proposed, though, is that it is easier to optimize (no new class or lots of extra objects to create and destroy).
Let's get back to the example, let's say that checking for «u» would return «nil», wouldn't checking for «u.profiles» would result in an exception thrown nonetheless?
Almost nothing is a primitive value in Ruby. Not even true/false/numbers are "traditional" primitive values.
> Let's get back to the example, let's say that checking for «u» would return «nil», wouldn't checking for «u.profiles» would result in an exception thrown nonetheless?
No, because `u.?profile` would return `nil`, then, when you try `nil.?thumbnail` on nil again, it would return nil. So, doing the following, with `u` being `nil` is legal:
if u.?profile.?thumbnail
# doesn't run if u is nil
endThat includes nil, true, false (instances of NilClass, TrueClass and FalseClass respectively).
A common way of explicitly checking for nil, as opposed to nil or false is to do "foo.nil?", for example, which explicitly calls the method nil? on foo, which will usually return false for objects other than nil (nothing stops you from overriding it if you want your class to pretend to be nil - e.g. maybe I'd want my "Maybe" class to return true for "nil?" if the value it holds is nil).
As for the example the whole point is that like my naive "Maybe" implementation, this new operator would check if the target is nil before trying to call a method. Unlike my naive implementation, it doesn't need to wrap objects, and it can short-circuit evaluation if it meets a nil (you can implement versions that will short-circuit evaluation too, but I can't see any obvious ways of both letting you short-circuit and getting "clean" syntax if you want to support method arguments).
(Or, better, alter the method that you get the user that you are getting "u" back from to return an "nonexistent user" object that responds to "profile" with a "nonexistent profile" object that responds to "thumbnails" with a single-item list containing a "nonexistent thumbnail" object that responds to a "large" method with a "nonexistent image" (or whatever) object that has the right behavior when used where an image object is expected in the code.
This approach allows replacing more conditionals with method implementations, and is in that sense more "object oriented" on that null-coalescing which still often requires passing the result to a conditional to handle the null case, and still takes some tricks to distinguish between the terminal method returning nil and something along the chain returning nil, where that differs in the handling.