• bvs23bkv33 (unregistered)

    where is my favourite bsearch with properly written comparators

  • ray10k (unregistered)

    My guess is, someone with less experience in JS than in another language figured, "I need some way to reference objects by a string key, and I don't trust javascript objects. Can't even rely on an object having a property..."

  • Jake Peralta (unregistered)

    You never know when JS/TS maps might break. Now, the Object Store... Now that's solid!

  • Hanzito (unregistered)

    Seeing there isn't a delete, this looks suspiciously like Array.

  • Anon (unregistered)

    ObjectStore is created with a free "toString" item!

  • Brian (unregistered)

    A set of objects stored with sequentially-numbered indices? What an amazing invention! We should give it a new name... "array" has a nice ring to it.

  • some ron (unregistered)

    Well... this is just a rant because the submitter doesn't understand why the object exists. Imagine the use case is to usually push objects, but you also want to change some later and you need some kind of ID, because the objects themselves do not provide such a thing. One idea would be to use store[autoid()]=obj, instead of store.push(obj), but the second one has a per-store unique id, where autoid() can only be global. Therefore store.push(obj) is a lot better than store[autoid(store)]=obj, and with the second you'd have to store the id in the map itself, like: autoid(store) { return ++store["counter"]; }, which would pollute the map, so whenever you use Object.keys(store) you'll have to remove "counter" to get only the actual IDs. If you now make functions for all that you are really close to the original object.

    But the real WTF is the implementation of _getNextUniqueKey which recursively increments the counter, every time checking whether the array of keys does not contain the current value. Why is nobody talking about that?

  • (nodebb)

    How about the fact that _getNextUniqueKey is recursive? Because it isn't WTFy enough unless you accidentally blow up the call stack?

  • (nodebb)

    Does this storage work like other storage offers: very low price for the first month (to get you in the door) and then an astronomical sum thereafter?

  • ooOOooGa (unregistered) in reply to Dragnslcr

    It will probably be fine. At least reliable enough to pass testing.

    Now, if _counter has somehow become a float and there are enough objects being stored that _counter++ === _counter, that might become a problem...

    But that should only happen in production.

  • steve76 (unregistered)

    I wonder what would happen to the program if you swapped out auto incremented keys with content hashing.

  • TruePony (unregistered)

    The programmer is saying they want "a raise".

  • Anonymous (unregistered) in reply to Dragnslcr

    I thought most engines treated that as a proper tail call, and avoided a ballooning call stack?

    Not defending it though. If that's the case it's likely dumb luck instead of actual knowledge.

  • But I *am* a robot! (unregistered)

    I almost wonder whether this is for obfuscation?

  • mmm (unregistered)

    If _counter is already used as a key when calling _getNextUniqueKey, it get's incremented twice! Better be sure :)

    Also, JS Objects and prototypal inheritance are a pretty good fit for their use case. JS Arrays are just a special kind of "object"/map, as others pointed out, pretty much like a working version of this abomination.

  • TechnicallyCorrect (unregistered)

    Also, _getNextUniqueKey is O(n) instead of O(1) - Object.keys(...).contains should instead be currentIndex in store. So many wonders, so little space!

  • Anon (unregistered)

    Methinks the genius behind this was a big time fan of the ol' Java way of doing things, where implementing an "ObjectStorage" like this would not only be encouraged, but necessary.

  • Thomas (unregistered) in reply to mmm

    No, it is actually not incremented twice. Thought so too, but since return (this._counter++) is first returning the current _counter value and then incrementing, this works actually out. Double increments could be "achieved" by writing return (++this._counter) instead ;-)

  • Thomas (unregistered) in reply to mmm

    You know what?! That's actually clever... I mean, still crappy, but clever crappy. Just take a moment to think it through... I call push(a), it writes a to 0 and increments the counter to 1. I call push (b), it writes b to 1 and increments the counter to 2. Now I call set(2, c), it writes c to 2 and the counter stays at 2. When I then call push(d), it realizes the key 2 is already in use, increments to 3, calls itself again, successfully writes d to 3 and increments the counter to 4.

    This means... they KNEW it was shitty having push AND set writing to the array, and made it "bullet proof" for the case that someone calls set in between of all the push calls.... :-D

  • WTFguy (unregistered)

    I haven't dug too deep into _getNextUniqueKey so I may be off base here. But I wonder if originally there was a delete(key) method, or at least the perceived requirement to be able to support a delete(key) method?

    In the presence of deletions, the _getNextUniqueKey as written doesn't deliver [highest key value]+1 but rather [first unused key value]. Which might be based on somebody's cockamamie belief that key reuse somehow saves either storage space or key values. At the obvious expense of returning the wrong (or at least unexpected) value if any other code held onto a key across a deletion made elsewhere.

    All in all, this is really a great foot-gun.

  • (nodebb)

    Also, no attempt to deal with the weird key values such as "constructor".

Leave a comment on “Going Down to the Object Store”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article