3 ms·

[] should be falsey so it can be used in an if(). I'm not sure about macros. I kind of want to see `with` back also. The problem with it was ambiguity. The

[] should be falsey so it can be used in an if(). I'm not sure about macros. I kind of want to see `with` back also. The problem with it was ambiguity. The syntax could be adjusted to avoid the ambiguity. .e.g `.prop = val;` could be legal inside the block. But "why though" you ask. A `with` block makes it visually obvious that a block of code is specifically relating to getters/setters on a particular object instance.

adam_arthur 5y ago
I'd argue truthiness implicated by the presence of an object is more logical than having an arbitrary definition of truthiness depending on the data type. If I have a cup that's empty, there's still a cup there. It's presumptuous to assume I care about the contents.
- recursive 5y ago
  In that case "" should be truthy. And 0 should be truthy too probably.
  - ckolkey 5y ago
    Yes and yes. Ruby got it right, no question :)
  - adam_arthur 5y ago
    They should be, to have consistency in design. Note that if the language operated this way, checks on these types would be more explicit (though more verbose too). Checking for presence of a number with a truthy check is a common source of errors, if 0 is a valid number. I just don't agree at all that Python's interpretation of truthiness (or equality, for that matter) is inherently the "right" one. If I clone somebody are they equal because they have the same genetic makeup? No. Though a pretty contrived example that requires common understanding of equality. At least from a programming perspective, I usually care more about instance equality rather than structural equality. Of course Python supports that too via the `is` keyword
- wwweston 5y ago
  There's a presumption either way. You can make the presumption JS did for [] (and there's probably no turning back), you can even argue explicit is better than implicit (vs the value of context-sensitive concision). But it's also not consistent with the ways that other empty but typed cups are treated ("" for the empty string, 0 for empty count / quantity, both of which are false-y). Different presumptions for different types of cups carries its own implicit hazards from context sensitivity.

adam_arthur 5y ago

I'd argue truthiness implicated by the presence of an object is more logical than having an arbitrary definition of truthiness depending on the data type. If I have a cup that's empty, there's still a cup there. It's presumptuous to assume I care about the contents.

recursive 5y ago
In that case "" should be truthy. And 0 should be truthy too probably.
- ckolkey 5y ago
  Yes and yes. Ruby got it right, no question :)
- adam_arthur 5y ago
  They should be, to have consistency in design. Note that if the language operated this way, checks on these types would be more explicit (though more verbose too). Checking for presence of a number with a truthy check is a common source of errors, if 0 is a valid number. I just don't agree at all that Python's interpretation of truthiness (or equality, for that matter) is inherently the "right" one. If I clone somebody are they equal because they have the same genetic makeup? No. Though a pretty contrived example that requires common understanding of equality. At least from a programming perspective, I usually care more about instance equality rather than structural equality. Of course Python supports that too via the `is` keyword
wwweston 5y ago
There's a presumption either way. You can make the presumption JS did for [] (and there's probably no turning back), you can even argue explicit is better than implicit (vs the value of context-sensitive concision). But it's also not consistent with the ways that other empty but typed cups are treated ("" for the empty string, 0 for empty count / quantity, both of which are false-y). Different presumptions for different types of cups carries its own implicit hazards from context sensitivity.