4 ms·

Messageable nil has a special place in my heart, but as a default mode of operation, it's certainly a fun way to hide bugs.

by oddity 9y ago

delinka 9y ago
Messages to nil ... sure, OK, fine. Allow that, but CRASH because someone sent an unhandled message? That’s just mean. Either crash when messaging nil, or don’t crash when improperly messaging an object.
- catnaroek 9y ago
  It doesn't matter how a language “handles nil or ‘not understood’ [sic] messages” - burning the computer would be okay. As with any other undesired behavior, it's your responsibility to prove it doesn't happen.
  - tomsmeding 9y ago
    I think that everyone here knows that programming without bugs is the ideal, but having the language work against doesn't really help in that regard, does it?
    - catnaroek 9y ago
      I wouldn't count “burning the computer under impossible conditions” as “working against”. It's just the principle of explosion at work, and pretty much any optimizing compiler that takes advantage of undefined behavior uses it.
  - yoz-y 9y ago
    No. In this case there is no undefined behaviour, the way this is handled is defined, but to the parent it seems inconsistent. Undesired behaviour can not be really leveraged for optimisation, and in any case, high(er) level languages should not have UB in their design.
    - catnaroek 9y ago
      If your program's correctness depends on `nil` being handled this or that way, your design is broken. Fortunately, most programs aren't designed this way: messages to `nil` are seldom actually intended, whether the language's semantics considers them a legitimate operation or not, and whether they are “helpfully” trapped at runtime or not.
- mpweiher 9y ago
  If you're talking about Objective-C: it doesn't crash. It sends the message -forwardInvocation: to the receiver. (Nowadays it might try a couple of other things first). Now the default implementation of -forwardInvocation: raises an exception, which in turn is by default unhandled and therefore goes to the default exception handler which logs and terminates. However, you can implement your own behavior at every level: 1. Override -forwardInvocation: for your own objects (or one of the other mechanisms) 2. Override -forwardInvocation: in NSObject 3. Handle the exception 4. Install your own default exception handler

Messageable nil has a special place in my heart, but as a default mode of operation, it's certainly a fun way to hide bugs.

by oddity 9y ago

Messageable nil has a special place in my heart, but as a default mode of operation, it's certainly a fun way to hide bugs.

delinka 9y ago

Messages to nil ... sure, OK, fine. Allow that, but CRASH because someone sent an unhandled message? That’s just mean. Either crash when messaging nil, or don’t crash when improperly messaging an object.

catnaroek 9y ago
It doesn't matter how a language “handles nil or ‘not understood’ [sic] messages” - burning the computer would be okay. As with any other undesired behavior, it's your responsibility to prove it doesn't happen.
- tomsmeding 9y ago
  I think that everyone here knows that programming without bugs is the ideal, but having the language work against doesn't really help in that regard, does it?
  - catnaroek 9y ago
    I wouldn't count “burning the computer under impossible conditions” as “working against”. It's just the principle of explosion at work, and pretty much any optimizing compiler that takes advantage of undefined behavior uses it.
- yoz-y 9y ago
  No. In this case there is no undefined behaviour, the way this is handled is defined, but to the parent it seems inconsistent. Undesired behaviour can not be really leveraged for optimisation, and in any case, high(er) level languages should not have UB in their design.
  - catnaroek 9y ago
    If your program's correctness depends on `nil` being handled this or that way, your design is broken. Fortunately, most programs aren't designed this way: messages to `nil` are seldom actually intended, whether the language's semantics considers them a legitimate operation or not, and whether they are “helpfully” trapped at runtime or not.
mpweiher 9y ago
If you're talking about Objective-C: it doesn't crash. It sends the message -forwardInvocation: to the receiver. (Nowadays it might try a couple of other things first). Now the default implementation of -forwardInvocation: raises an exception, which in turn is by default unhandled and therefore goes to the default exception handler which logs and terminates. However, you can implement your own behavior at every level: 1. Override -forwardInvocation: for your own objects (or one of the other mechanisms) 2. Override -forwardInvocation: in NSObject 3. Handle the exception 4. Install your own default exception handler