4 ms·

I think a good case could be made that, if you're designing a new dynamically typed language from scratch that doesn't have to support older code, safe array/ob

by Udo 11y ago

I think a good case could be made that, if you're designing a new dynamically typed language from scratch that doesn't have to support older code, safe array/object navigation should be the default. 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.

skrebbel 11y ago
I wildly disagree, because I get waking nightmares from the amount of implicit "wtf why doesn't it even enter my method" behavior that would imply, but I upvoted you because I think it's a very interesting idea and I wonder what others think.
- Udo 11y ago
  I agree that the invokation idea is relatively wild, that's why I made it into a separate point. There are somewhat successful languages out there where sending a message to a null object doesn't do anything. If this is a class of bug that happens to you frequently, it's probably not for you. But once you get into the mindset that each method call is prepended by a virtual conditional, my hunch is you would know pretty quickly why your method isn't being called.
  - bjeanes 11y ago
    And most Objective-C (one of those languages) developers I've talked to about this would recall nightmares about that behaviour.
    - Udo 11y ago
      It's debatable whether this behavior was a good fit for Objective-C, since it's not actually a dynamically typed language. People reasonably expect their Obj-C compiler to do static checks and in this context dynamic behavior is an unwelcome surprise. It would be interesting if, for example, Smalltalk developers share the same frustration. My guess would be: probably not. 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.
      - cballard 11y ago
        Objective-C is definitely dynamically typed, feel free to use "id" and go to town. To say nothing of swizzling.
    - dazmax 11y ago
      The main problem I've seen with Objective-C is due to the fact that nil has truthiness, so this code is dangerous: if (input.isInvalid()) { reject() } else { accept() } If input is accidentally nil, it's an invisible bug. 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.
      - cballard 11y ago
        Huh? (int)nil == 0
      - uxp 11y ago
        This is entirely incorrect. nil 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"]; if user.profile.name is nil, then that expression evaluates to the value 0, which as we discovered, is the _only value that evaluates to false in C_
  - Peaker 11y ago
    I see this behavior as implicit error silencing. Wouldn't you prefer seeing: foo .? bar . baz .? roo To know that nil is not even a possibility for `bar`? Why not make the nil check (or error silencing) explicit when it is so cheap to do so?
    - Udo 11y ago
      I already talked about my reasoning. But you are correct when you say this is a form of implicit error silencing. Dynamic languages usually have many features which could be described as implicit error silencing, and even statically typed ones often do. Implicit type conversions would be an example. You could very well argue any behavior that deviates from how the processor architecture handles data types and conditionals constitutes a silenced error of some kind. The question becomes where you personally draw the line.
      - Peaker 11y ago
        Indeed I believe in Python's motto of "Errors should never pass silently. Unless explicitly silenced." 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.
  - noblethrasher 11y ago
    > There are somewhat successful languages out there where sending a message to a null object doesn't do anything. 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.
- deleted 11y ago
  [deleted]
MatmaRex 11y ago
PHP does this (with a warning). I'm not sure if this should be an argument for or against. <?php $foo = array(); echo $foo['a']['b']['c']; // not an error
- vidarh 11y ago
  Here's a slightly evil way of handling this specific case in Ruby: d = lambda {|hash,key| Hash.new(&d) } foo = Hash.new(&d) p foo['a']['b']['c'] The argument to "Hash.new" is the default value, or a on object that takes the hash object itself and the key, and returns the default value (and optionally stores it in the hash, which makes it great for memoization). In this case, whenever accessing a non-existent hash key, it returns another hash with the same closure as the default... 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.
- juriansluiman 11y ago
  That's where the coalesce operator ("??") is for. Exactly to suppress the warning and avoid verbose isset() calls: echo $foo['a']['b'] ?? 'default_value';
  - Udo 11y ago
    I'm looking forward to this in PHP7. My current workaround, which exists for the same reason as the coalesce operator (https://wiki.php.net/rfc/isset_ternary https://wiki.php.net/rfc/isset_ternary) is a custom function: $v = @first($var1, $var2, 'some-default'); which will simply return the first parameter that has a non-null, non-empty-string value.
dragonwriter 11y ago
If you don't have a legacy burden, just including and having the standard library use something like Maybe with a good comprehension syntax seems better than adopting the antipattern of using nil all over the place to start with.
deleted 11y ago
[deleted]

by Udo 11y ago

skrebbel 11y ago

I wildly disagree, because I get waking nightmares from the amount of implicit "wtf why doesn't it even enter my method" behavior that would imply, but I upvoted you because I think it's a very interesting idea and I wonder what others think.

Udo 11y ago
I agree that the invokation idea is relatively wild, that's why I made it into a separate point. There are somewhat successful languages out there where sending a message to a null object doesn't do anything. If this is a class of bug that happens to you frequently, it's probably not for you. But once you get into the mindset that each method call is prepended by a virtual conditional, my hunch is you would know pretty quickly why your method isn't being called.
- bjeanes 11y ago
  And most Objective-C (one of those languages) developers I've talked to about this would recall nightmares about that behaviour.
  - Udo 11y ago
    It's debatable whether this behavior was a good fit for Objective-C, since it's not actually a dynamically typed language. People reasonably expect their Obj-C compiler to do static checks and in this context dynamic behavior is an unwelcome surprise. It would be interesting if, for example, Smalltalk developers share the same frustration. My guess would be: probably not. 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.
    - cballard 11y ago
      Objective-C is definitely dynamically typed, feel free to use "id" and go to town. To say nothing of swizzling.
  - dazmax 11y ago
    The main problem I've seen with Objective-C is due to the fact that nil has truthiness, so this code is dangerous: if (input.isInvalid()) { reject() } else { accept() } If input is accidentally nil, it's an invisible bug. 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.
    - cballard 11y ago
      Huh? (int)nil == 0
    - uxp 11y ago
      This is entirely incorrect. nil 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"]; if user.profile.name is nil, then that expression evaluates to the value 0, which as we discovered, is the _only value that evaluates to false in C_
- Peaker 11y ago
  I see this behavior as implicit error silencing. Wouldn't you prefer seeing: foo .? bar . baz .? roo To know that nil is not even a possibility for `bar`? Why not make the nil check (or error silencing) explicit when it is so cheap to do so?
  - Udo 11y ago
    I already talked about my reasoning. But you are correct when you say this is a form of implicit error silencing. Dynamic languages usually have many features which could be described as implicit error silencing, and even statically typed ones often do. Implicit type conversions would be an example. You could very well argue any behavior that deviates from how the processor architecture handles data types and conditionals constitutes a silenced error of some kind. The question becomes where you personally draw the line.
    - Peaker 11y ago
      Indeed I believe in Python's motto of "Errors should never pass silently. Unless explicitly silenced." 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.
- noblethrasher 11y ago
  > There are somewhat successful languages out there where sending a message to a null object doesn't do anything. 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.
deleted 11y ago
[deleted]

MatmaRex 11y ago

PHP does this (with a warning). I'm not sure if this should be an argument for or against. <?php $foo = array(); echo $foo['a']['b']['c']; // not an error

vidarh 11y ago
Here's a slightly evil way of handling this specific case in Ruby: d = lambda {|hash,key| Hash.new(&d) } foo = Hash.new(&d) p foo['a']['b']['c'] The argument to "Hash.new" is the default value, or a on object that takes the hash object itself and the key, and returns the default value (and optionally stores it in the hash, which makes it great for memoization). In this case, whenever accessing a non-existent hash key, it returns another hash with the same closure as the default... 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.
juriansluiman 11y ago
That's where the coalesce operator ("??") is for. Exactly to suppress the warning and avoid verbose isset() calls: echo $foo['a']['b'] ?? 'default_value';
- Udo 11y ago
  I'm looking forward to this in PHP7. My current workaround, which exists for the same reason as the coalesce operator (https://wiki.php.net/rfc/isset_ternary https://wiki.php.net/rfc/isset_ternary) is a custom function: $v = @first($var1, $var2, 'some-default'); which will simply return the first parameter that has a non-null, non-empty-string value.

dragonwriter 11y ago

If you don't have a legacy burden, just including and having the standard library use something like Maybe with a good comprehension syntax seems better than adopting the antipattern of using nil all over the place to start with.

deleted 11y ago

[deleted]