-1

I was presented with this argument when fixing a bug related to implicit casting and speaking to the developer who told me:

If you use Closure, then you do not need absolute equality. Any value would be typed, therefor you don't need to worry about implicit casts.

My response was, that's dicey. You're making a lot of assumptions; Closure does not alter JavaScript, it's primarily a labyrinthine super layer (aside: probably a moot one, now that we have TypeScript).

Anyway, if one of these implicit things does slip by because the annotations don't resolve perfectly for some reason, you can end up with a tough bug (which is what happened; it got assigned to me because I guess the other dev didn't think it could be the problem).

I got responses of, "well if that dev had properly typed that object and this wasn't just an object and..."

Or...you could just protect against this sort of thing easily by using three equal signs instead of two. Use an assertion or console log to check the condition if necessary. Don't just leave it hanging out there.

Anyway what do you think; if you're using Closure, should you still observe the general best practice of using absolute equality in your JS code?

I know this leads to a wider conversation as well (e.g. Java 8's "optional" being "totally useless"), curious in the context of Closure though.

Chad Killingsworth
  • 14,360
  • 2
  • 34
  • 57
Tim Consolazio
  • 4,802
  • 2
  • 19
  • 28

1 Answers1

0

Question is a bit vague, code example would have helped. But yes, closure does not necessarily type every object and variable. I always use === unless there is a specific reason not to.

Paul
  • 595
  • 6
  • 6
  • I wan't comfortable with a code example as the code that originated it was owned code, even providing a "close" example could be misconstrued. The basic discussion is valid though, if you use Closure with all advanced optimizations etc. does it mean you can abandon the === general best practice. The answer I eventually came to think is, that since Closure attempts to make JS very Java-like, it's not surprising to have a trained Java dev think this way. But I don't think any professional JS dev that works in more than one particular place would agree. – Tim Consolazio Jan 06 '17 at 15:55