Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

  > if (1) { ... } will never execute, because 1 is a
  > number, not a boolean,
This hasn't stopped Ruby from being popular.


In Ruby it's the other way around: 1 is truthy and the block will execute. Everything in Ruby is truthy other than the null reference and Boolean false.

I can understand forbidding non-Boolean values in Boolean contexts - it's not something I'd want myself but I think I get why a reasonable person might. Dart's semantics, though, are really strange: they follow no precedent I'm aware of, and don't seem to offer anything useful in themselves. Does anyone else have some insight here?


dart's boolean context semantics are like taking smalltalk's strongly typed ones and putting them through something.. i don't know what they were thinking. the basic idea is sound ( the smalltalk part ) but what they then did around the 'edges' is just downright off.


I guess you mean the opposite hasn't prevented Ruby from being popular. All numeric values are truthy, including 0.


A lot of Ruby idiomatic methods will return either a value or nil, which is falsey, so things like:

  x = meep
  if x
    # do stuff
  end
will run as most might mean.


  > I guess you mean the opposite hasn't
  > prevented Ruby from being popular.
I was stating something more like "the fact that there is a hard split between numbers and booleans, and everything -- barring null -- by default evaluates to true." Since everything is a object instance in Ruby, asserting a variable is basically only evaluating whether or not it is null.


null or false, actually.


Slip of the tongue. ;) But the easiest way to think about it is something like:

  type(x) == Boolean ? x == True : x != nil
Disclaimer: That may not be valid Ruby, as I only have a passing knowledge of some bits of Ruby.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: