7 ms·

Mind explaining the ==/=== issue which arises from the high/lo and array solution?

• MaulingMonkey 9y ago
  As parent mentions, comparison with ==/=== are "broken" for arrays or classes. Or more accurately, they now do reference comparisons instead of value comparisons. This means you have to replace a lot of this (using Flash/ActionScript as the example here): function updateIcon(id: int, ...) { for (var icon in icons) { if (icon.id === id) { ... } } } With, say, something like this: function updateIcon(id: Ptr, ...) { for (var icon in icons) { if (Ptr.compare(icon.id, id) === 0) { ... } } } Or: function updateIcon(id: Array, ...) { for (var icon in icons) { if (ObjectUtil.compare(icon.id, id) === 0) { ... } } } Assuming you want to preserve the exact semantics of the existing code. If you miss a single comparison, your code will still compile. You will get no runtime exceptions, because == and === are still legal. It'll just have a subtle runtime flaw that will only manifest itself if two interop sites construct the same pointer value as different Ptr or array instances without interning (read: caching/leaking Ptr or array instances, which has it's own problems.) You cannot override == or === to do the right thing (tm) either. In the unlikely event you do a large refactoring or conversion completely flawlessly, your coworker's muscle memory will, rather understandably, still end up causing problems. function updateIcon(id: String, ...) { for (var icon in icons) { if (icon.id === id) { ... } } } This is less refactoring, and just works(tm), because String ==/=== already compares the value of the strings. No muscle memory to update, easier to print in debug and trace statements, etc...