2 ms·

You should learn some more javascript. The language itself is pretty sweet. Individual implementations vary. Your image just shows you don't understand very mu

by axod 18y ago

You should learn some more javascript. The language itself is pretty sweet. Individual implementations vary. Your image just shows you don't understand very much about the language. It's not "wrong" once you understand what it's doing and why. Show it to anyone who understands what is happening, and you'll look quite foolish. It's not massively complex once you read "Javascript: The definitive guide (O'Reily)" - the best book on js by a mile. var obj1 = {}; // var doesn't return anything, so the interpreter shows 'undefined'. var obj2 = {}; // same again obj1 == obj2; // Well no, they're different objects. So you'll get false var thing = {}; // thing[obj1] = "hi"; // OK this is an odd thing to want to do, but you're doing it anyway. // You're using an *object* (obj1), as a key. // The js thinks you're idiotic, but complies by calling the .toString() method, // and gets "[object Object]" or similar by default. // (You're free to override that on your object). thing[obj2] // Once again, you're using an object as a key // and acting surprised that js has changed it into a string. // So, you created an object and set thing["object Object"] = "hi" So instead of "Wow! js is retarded", my response to that code would be "Why is he trying to use objects as keys? and why is he surprised when js converts them to strings?" I recommend the above book to clear up things like this.

tumult 18y ago
Read it again, the problem is that it accepts it silently and does not indicate any sort of irregular behavior in an operation that shouldn't work that way. It just does it and then fails weirdly in the future. I fully understand how equality works in JavaScript (especially after making the mistake pictured.) Also, the existence of an "===" operator should be troubling. Many people writing JS don't even know it exists. edit: when you extend your reply in a large way, please append it with "edit:" or just make a new reply, thanks :]
- axod 18y ago
  Why shouldn't it work that way??? It's silently doing type conversion for you - from an object to a string. That's desired behavior. Just as most languages presented with "foo"+12 would silently convert 12 to a string via the toString() method. What way do you think it should work? :/ An example of more sane usage: >>> var myv={} >>> var foo={toString:function(){return "12"}} >>> myv[foo]=34 34 >>> myv[12] 34 >> "Also, the existence of an "===" operator should be troubling. Many people writing JS don't even know it exists." You can't fault a language because some people don't make the effort to learn it properly.
  - tumult 18y ago
    I'm a karma burning mood so I'll keep going :] This is the main problem I have with it; it's a very dynamic language but in a totally dangerous way. It should hash based on an object's identity or something; as it stands, there's no way to do that in JS without bolting your own junk on top, as a result you can't do real object<->object associations in JS. Python for example has well-defined and useful behavior when you shove something into a dict type as a key, for strings it will hash based on the string value, for some other things it will uses identity, etc., and you can overload it (which you can in JS too of course, as you showed.)
    - axod 18y ago
      maybe the default toString() should be a unique ID, as it is in for example Java, but it's not really a big deal. How often do you need object A->object B associations like that? Far easier to just put a pointer in all the object As to point to object Bs, and then put the object A's in an object/array. Your use case is not something I've ever needed to be honest, and if you need it, it's simple to build it out yourself. For example, in an object constructor, just replace the toString() to return a unique ID for that object. A line of code :/ It's only dangerous when you don't understand what is happening. Why didn't you research why your image example was confusing you? As I say, read the book.
      - tumult 18y ago
        How often do you need object A->object B associations like that? Far easier to just put a pointer in all the object As to point to object Bs This gives us an equivalent mapping, but unfortunately it alters the original object by adding a property to it. This sucks for two reasons; one is that the names might clash with a property that something else has set on that object, so you end up creating terrible names to avoid collisisions like someObject._prviate_associatedOtherObject or something, and then you have to make sure to destroy it when appropriate. It gets more hairy if you need multiple relations between the same objects. The other problem is that when you enumerate an object, now that property will show up. Gross. Yes, I know about the boilerplate you use to make enumerations in JS safe; my argument is that JS sucks as a language, and the necessity of stuff like this contributes to it. For example, in an object constructor, just replace the toString() to return a unique ID for that object. A line of code :/ The Cappuccino/Objective-J guys at 280North have to do something similar (grep for OBJECT_COUNT++ in the source to see what I mean) in order to add identity to Obj-J objects.. but what if you didn't instantiate the object yourself? And I think this is the case where you'd be most likely to want to perform a mapping on an opaque object.

by axod 18y ago

tumult 18y ago

Read it again, the problem is that it accepts it silently and does not indicate any sort of irregular behavior in an operation that shouldn't work that way. It just does it and then fails weirdly in the future. I fully understand how equality works in JavaScript (especially after making the mistake pictured.) Also, the existence of an "===" operator should be troubling. Many people writing JS don't even know it exists. edit: when you extend your reply in a large way, please append it with "edit:" or just make a new reply, thanks :]

axod 18y ago
Why shouldn't it work that way??? It's silently doing type conversion for you - from an object to a string. That's desired behavior. Just as most languages presented with "foo"+12 would silently convert 12 to a string via the toString() method. What way do you think it should work? :/ An example of more sane usage: >>> var myv={} >>> var foo={toString:function(){return "12"}} >>> myv[foo]=34 34 >>> myv[12] 34 >> "Also, the existence of an "===" operator should be troubling. Many people writing JS don't even know it exists." You can't fault a language because some people don't make the effort to learn it properly.
- tumult 18y ago
  I'm a karma burning mood so I'll keep going :] This is the main problem I have with it; it's a very dynamic language but in a totally dangerous way. It should hash based on an object's identity or something; as it stands, there's no way to do that in JS without bolting your own junk on top, as a result you can't do real object<->object associations in JS. Python for example has well-defined and useful behavior when you shove something into a dict type as a key, for strings it will hash based on the string value, for some other things it will uses identity, etc., and you can overload it (which you can in JS too of course, as you showed.)
  - axod 18y ago
    maybe the default toString() should be a unique ID, as it is in for example Java, but it's not really a big deal. How often do you need object A->object B associations like that? Far easier to just put a pointer in all the object As to point to object Bs, and then put the object A's in an object/array. Your use case is not something I've ever needed to be honest, and if you need it, it's simple to build it out yourself. For example, in an object constructor, just replace the toString() to return a unique ID for that object. A line of code :/ It's only dangerous when you don't understand what is happening. Why didn't you research why your image example was confusing you? As I say, read the book.
    - tumult 18y ago
      How often do you need object A->object B associations like that? Far easier to just put a pointer in all the object As to point to object Bs This gives us an equivalent mapping, but unfortunately it alters the original object by adding a property to it. This sucks for two reasons; one is that the names might clash with a property that something else has set on that object, so you end up creating terrible names to avoid collisisions like someObject._prviate_associatedOtherObject or something, and then you have to make sure to destroy it when appropriate. It gets more hairy if you need multiple relations between the same objects. The other problem is that when you enumerate an object, now that property will show up. Gross. Yes, I know about the boilerplate you use to make enumerations in JS safe; my argument is that JS sucks as a language, and the necessity of stuff like this contributes to it. For example, in an object constructor, just replace the toString() to return a unique ID for that object. A line of code :/ The Cappuccino/Objective-J guys at 280North have to do something similar (grep for OBJECT_COUNT++ in the source to see what I mean) in order to add identity to Obj-J objects.. but what if you didn't instantiate the object yourself? And I think this is the case where you'd be most likely to want to perform a mapping on an opaque object.