4 ms·

Doesn't this just encourage lazy and vague programming? It sounds like it cuts down on a lot of checks in certain situations, but I'm struggling to think of a c

Doesn't this just encourage lazy and vague programming? It sounds like it cuts down on a lot of checks in certain situations, but I'm struggling to think of a coding pattern that's actually well designed that requires so many checks at the last minute without knowing what type and data you're dealing with.

moonshinefe 11y ago
To clarify, in the article linked they give this example: u.?profile.?thumbnails.?large Using that operator a single time or whatnot seems handy, but chaining it like that just seems like poor practice to me.
- deckiedan 11y ago
  It's in deep nesting like that that such an operator really comes into its own. If you only use it for single cases, it really isn't worth it. 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 repeats u 5 times, and the entire u.profiles.thumbnails.large twice! 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 And even the super verbose version there still can raise exceptions when you get slightly mad data - say you decode some JSON which has u.profile.thumbnails as "null" (a string) rather than actually a null. asking if u.profile.thumbnails will be true - but when you request u.profile.thumbnails.large, you blow up. 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 which (alas) also will catch all noMethodErrors in do_something_with. So you then end up with begin tmp = u.profile.thumbnails.large rescue tmp = nil end if tmp do_something(tmp) end which is super ugly. 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.
  - vidarh 11y ago
    And it's worth pointing out that the above is also slow whether you depend on exceptions or just the long if version, and depends on having methods with no side-effects, as several methods gets called multiple times. 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
- dragonwriter 11y ago
  > Using that operator a single time or whatnot seems handy, but chaining it like that just seems like poor practice to me. The whole motivation of the operator is for chaining.
maniacalrobot 11y ago
Many delegator patterns allow for "fire and forget" messaging to objects that might have not been set at runtime. This is a very useful feature/short-cut to have in a high-level language like Ruby, where the nil checks can be performed by the runtime, and not the application code.
icebraining 11y ago
You still have to know the type, this only works for nil, so if you do "obj.?name" and the obj is not nill but doesn't have a "name" attribute, it'll blow up. It's essentially syntax sugar to save time when you want to do something iff the whole chain is filled in.
nailer 11y ago
Every REST API? Third part objects need to be checked, and aren't always in the shape you expect.

moonshinefe 11y ago

To clarify, in the article linked they give this example: u.?profile.?thumbnails.?large Using that operator a single time or whatnot seems handy, but chaining it like that just seems like poor practice to me.

deckiedan 11y ago
It's in deep nesting like that that such an operator really comes into its own. If you only use it for single cases, it really isn't worth it. 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 repeats u 5 times, and the entire u.profiles.thumbnails.large twice! 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 And even the super verbose version there still can raise exceptions when you get slightly mad data - say you decode some JSON which has u.profile.thumbnails as "null" (a string) rather than actually a null. asking if u.profile.thumbnails will be true - but when you request u.profile.thumbnails.large, you blow up. 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 which (alas) also will catch all noMethodErrors in do_something_with. So you then end up with begin tmp = u.profile.thumbnails.large rescue tmp = nil end if tmp do_something(tmp) end which is super ugly. 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.
- vidarh 11y ago
  And it's worth pointing out that the above is also slow whether you depend on exceptions or just the long if version, and depends on having methods with no side-effects, as several methods gets called multiple times. 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
dragonwriter 11y ago
> Using that operator a single time or whatnot seems handy, but chaining it like that just seems like poor practice to me. The whole motivation of the operator is for chaining.

maniacalrobot 11y ago

Many delegator patterns allow for "fire and forget" messaging to objects that might have not been set at runtime. This is a very useful feature/short-cut to have in a high-level language like Ruby, where the nil checks can be performed by the runtime, and not the application code.

icebraining 11y ago

You still have to know the type, this only works for nil, so if you do "obj.?name" and the obj is not nill but doesn't have a "name" attribute, it'll blow up. It's essentially syntax sugar to save time when you want to do something iff the whole chain is filled in.

nailer 11y ago

Every REST API? Third part objects need to be checked, and aren't always in the shape you expect.