5 ms·

> There are plenty of times where you want == FWIW, I've never used ==

Udik 10y ago
FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.
- lloyd-christmas 10y ago
  > I'm used to javascript enough to think in advance I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons: 1) debugging someone else's code is a lot more time consuming than debugging your own 2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code 3) the docs are simpler to write and easier to read. It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality: function doStuff(a, b, c) { if (!c && b instanceof Function) { c = b; } c() } "`doStuff` takes 2 or 3 arguments, depending on what you feel like giving it." I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.
  - tracker1 10y ago
    It's my opinion that if I can execute without error, I should execute without error... if that means I `~~input` to make certain I'm working with a whole number, I'll do it. If someone calls me with invalid input, and it's coerced and you get invalid output, so be it.. it didn't crash/error. That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.
    - lloyd-christmas 10y ago
      > so be it.. it didn't crash/error. That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem". > If someone calls me with invalid input, and it's coerced and you get invalid output But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.
  - goatlover 10y ago
    Multiple dispatch would be a cleaner approach for languages that support multiple versions of doStuff.
  - Udik 10y ago
    True, although your example is probably just an attempt to offer method overloading. But I agree that it is confusing. And you do see a lot of times functions trying to sanitise their inputs, which I agree is wrong.
- deleted 10y ago
  [deleted]

Udik 10y ago

FWIW, I almost always use ==. Very rarely, if ever, had any problems- probably I'm used to javascript enough to think in advance of the edge cases and use === when I feel it's necessary.

lloyd-christmas 10y ago
> I'm used to javascript enough to think in advance I don't consider it a foresight issue. I'm a believer in putting the burden on the caller not the callee. If I expect 0 and you have "0", it's your job to call parseInt(), not my job to branch out some if statements for type checking and coercion. For a few reasons: 1) debugging someone else's code is a lot more time consuming than debugging your own 2) actually fixing a bug in someone else's code means a pull request to someone who may not actively maintain that code 3) the docs are simpler to write and easier to read. It's my only pain point with the JS community. The "give me whatever and I'll see if I can handle it for you" mentality: function doStuff(a, b, c) { if (!c && b instanceof Function) { c = b; } c() } "`doStuff` takes 2 or 3 arguments, depending on what you feel like giving it." I'd rather be expressly told what to give you than try to read a wall of if statements in both the docs and your code.
- tracker1 10y ago
  It's my opinion that if I can execute without error, I should execute without error... if that means I `~~input` to make certain I'm working with a whole number, I'll do it. If someone calls me with invalid input, and it's coerced and you get invalid output, so be it.. it didn't crash/error. That said, the biggest problem I've seen in a lot of projects, bigger than coercion and in languages including, but not limited to JS is not properly handling error cases.
  - lloyd-christmas 10y ago
    > so be it.. it didn't crash/error. That's a HUGE problem. This is an absolutely fucking nightmare. It's arguably the hardest thing to possibly debug, because you're not informed it's a bug. No amount of error handling will solve that, which you've pointed out as "the biggest problem". > If someone calls me with invalid input, and it's coerced and you get invalid output But this isn't the problem. The problem is when it gets called with invalid input and somehow gets coerced into a valid but unexpected output. Expected input -> Expected output means you get instant gratification as to whether or not it works. This dramatically reduces the number of error cases which naturally and effortlessly moves toward solving your complaint.
- goatlover 10y ago
  Multiple dispatch would be a cleaner approach for languages that support multiple versions of doStuff.
- Udik 10y ago
  True, although your example is probably just an attempt to offer method overloading. But I agree that it is confusing. And you do see a lot of times functions trying to sanitise their inputs, which I agree is wrong.
deleted 10y ago
[deleted]