5 ms·

Byt anyone with even a basic tutorial understanding of the language wouldn't do that. Is it really necessary to try and make it absolutely impossible to get un

Byt anyone with even a basic tutorial understanding of the language wouldn't do that. Is it really necessary to try and make it absolutely impossible to get unexpected results? The downside is even more complexity and uncertainty. Now you have to know the old way, the new way, and the idiosynchracies of both.

haberman 15y ago
You might not write: dict["valueOf"] since that's obviously a bad idea, but you might write: dict[user_provided_string] Since user_provided_string could be anything, you are susceptible to unexpected behavior if the string ends up being "valueOf".
- grannyg00se 15y ago
  But even if you use an arbitrary object....if it comes from a user supplied value you are going to have to validate it somehow. It would be great if the post included good examples of how these things are going to produce better code. Maybe my imagination or experience is just insufficient to see the great win here.
  - tolmasky 15y ago
    Validated or not there are still many cases where this is a valid key and thus completely breaks the object. For example, this might be a login name, most people would consider it unreasonable to not allow js keywords as logins. For a simpler example, imagine a dictionary of syntax highlighted words for js ;) There are workarounds of course, but the ironic result is that when you want to use a js object as an actual hash/dictionary (something we are repeatedly told js is great at), your code devolves into a defensive programming mess, requiring constructions like Object.prototype.hasOwnProperty.apply, etc.
- btilly 15y ago
  But instead if you write: dict[ "_" + user_provided_string ] then nothing can ever go wrong. This does have an annoyance around the leading underscores. But you can get around that by adding simple accessor methods. And now you have a real dictionary. But native dictionaries have the ability to store complex objects as keys. This is kind of nice. However they are likely to create traps like making these 2 different: my_dict[5], my_dict['5']
  - ootachi 15y ago
    "then nothing can ever go wrong." What about the key "_proto__" (forming "__proto__") [1]? That will screw up your dictionary badly. It's not so easy. Which is why you want Harmony Maps and Sets in the first place. [1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/proto https://developer.mozilla.org/en/JavaScript/Reference/Global...
    - btilly 15y ago
      Good point. I shouldn't have tossed that off of the top of my head, particularly since I'm not a JavaScript programmer. But the principle is right, you just need a different starting key than "_" to avoid conflict. Something like, "dict_" should work. And hide the details behind accessors. So if that breaks in a future version of JavaScript, it is easy to change it again.
  - batista 15y ago
    then nothing can ever go wrong. Yes, let's add some arbitrary personal convention you have to follow and keep track of, because it's so much easy than a proper Map type... But you can get around that by adding simple accessor methods. And now you have a real dictionary. You still don't have a real dictionary, keys are only strings for example. You just have another lame-ass implementation of a dict in JS that avoids some edge cases and still falls prey to others. However they are likely to create traps like making these 2 different: my_dict[5], my_dict['5'] Those two ARE different.
    - btilly 15y ago
      Those two are different, but JavaScript does not encourage clarity about when you'll have one versus the other, thereby leading to traps for unwary beginners.

haberman 15y ago

You might not write: dict["valueOf"] since that's obviously a bad idea, but you might write: dict[user_provided_string] Since user_provided_string could be anything, you are susceptible to unexpected behavior if the string ends up being "valueOf".

grannyg00se 15y ago
But even if you use an arbitrary object....if it comes from a user supplied value you are going to have to validate it somehow. It would be great if the post included good examples of how these things are going to produce better code. Maybe my imagination or experience is just insufficient to see the great win here.
- tolmasky 15y ago
  Validated or not there are still many cases where this is a valid key and thus completely breaks the object. For example, this might be a login name, most people would consider it unreasonable to not allow js keywords as logins. For a simpler example, imagine a dictionary of syntax highlighted words for js ;) There are workarounds of course, but the ironic result is that when you want to use a js object as an actual hash/dictionary (something we are repeatedly told js is great at), your code devolves into a defensive programming mess, requiring constructions like Object.prototype.hasOwnProperty.apply, etc.
btilly 15y ago
But instead if you write: dict[ "_" + user_provided_string ] then nothing can ever go wrong. This does have an annoyance around the leading underscores. But you can get around that by adding simple accessor methods. And now you have a real dictionary. But native dictionaries have the ability to store complex objects as keys. This is kind of nice. However they are likely to create traps like making these 2 different: my_dict[5], my_dict['5']
- ootachi 15y ago
  "then nothing can ever go wrong." What about the key "_proto__" (forming "__proto__") [1]? That will screw up your dictionary badly. It's not so easy. Which is why you want Harmony Maps and Sets in the first place. [1]: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/proto https://developer.mozilla.org/en/JavaScript/Reference/Global...
  - btilly 15y ago
    Good point. I shouldn't have tossed that off of the top of my head, particularly since I'm not a JavaScript programmer. But the principle is right, you just need a different starting key than "_" to avoid conflict. Something like, "dict_" should work. And hide the details behind accessors. So if that breaks in a future version of JavaScript, it is easy to change it again.
- batista 15y ago
  then nothing can ever go wrong. Yes, let's add some arbitrary personal convention you have to follow and keep track of, because it's so much easy than a proper Map type... But you can get around that by adding simple accessor methods. And now you have a real dictionary. You still don't have a real dictionary, keys are only strings for example. You just have another lame-ass implementation of a dict in JS that avoids some edge cases and still falls prey to others. However they are likely to create traps like making these 2 different: my_dict[5], my_dict['5'] Those two ARE different.
  - btilly 15y ago
    Those two are different, but JavaScript does not encourage clarity about when you'll have one versus the other, thereby leading to traps for unwary beginners.