Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
  • Jul 25 2019 23:17
    Natanagar opened #25
  • Feb 15 2019 02:31
    damathryx commented #10
  • Oct 16 2018 02:39
    lookfirst commented #24
  • Oct 15 2018 21:49
    benjamin-hg commented #24
  • Oct 14 2018 20:45
    benjamin-hg commented #23
  • Oct 14 2018 20:43
    benjamin-hg commented #24
  • Oct 14 2018 20:39
    benjamin-hg commented #23
  • Oct 14 2018 20:37
    benjamin-hg edited #23
  • Oct 14 2018 20:35
    benjamin-hg reopened #23
  • Oct 14 2018 20:06
    benjamin-hg closed #23
  • Oct 14 2018 20:03
    benjamin-hg opened #24
  • Oct 14 2018 18:08
    benjamin-hg opened #23
  • Oct 10 2018 18:36
    moodysalem closed #14
  • Jan 25 2018 16:03
    roni-frantchi synchronize #22
  • Jan 25 2018 15:14
    roni-frantchi opened #22
  • Dec 26 2017 11:51
    Dharmik8478 synchronize #21
  • Dec 26 2017 11:50
    Dharmik8478 edited #21
  • Dec 26 2017 11:47
    Dharmik8478 opened #21
  • Jul 06 2017 07:26
    lookfirst commented #20
  • Jul 06 2017 06:55
    lucash commented #20
Moody Salem
Jeff, the javascript implementation of the JSOG decoder assumes that each @ref is encountered after the corresponding @id in the serialization. Map implementations do not necessarily preserve key insertion order, and neither does JSON.parse. As a result, the algorithm cannot be copied to other platforms reliably. The example implementation of a parser should be rewritten IMO to handle the general case where a @ref can point to an @id anywhere in the JSON. My idea is that you would 1. loop through the JSON to get a map of all @id values to their corresponding objects 2. loop through the JSON to get a map of @ref values to an array of dictionary/keys || array/indices 3. loop through all the ref points and look up the @id, throwing an exception if an ID is not found. Steps 1 and 2 can be done together in a single pass.
Jeff Schnitzer
If you're looking for an algorithm to copy for a platform that doesn't preserve map insertion order, look at the Python impl
Moody Salem
Cool :) Maybe the JS implementation should be converted to follow the same algorithm?
Jeff Schnitzer
Why? The JS implementation works great and the unordered-dict algorithm is less efficient.
Moody Salem
JavaScript objects by definition are not expected to preserve any kind of key order, so the implementation is susceptible to bugs with changes to JavaScript engines
Plus it seems cleaner to use a single algorithm with reference implementations in multiple languages, otherwise it's not clear how to implement this in other languages such as Objective-C
Jeff Schnitzer
I'm aware that the official JS spec does not define ordered behavior of maps. I'm also aware that all JS engines in existence actually do enforce this behavior, and in fact there's a famous release of a past version of Chrome that relaxed this behavior, caused a ton of problems, and they quickly re-instituted the behavior. So the de-facto JS standard is that objects are ordered; I challenge you to find an engine that does not enforce this constraint.
Furthermore, ES6 makes the ordering constraint explicit. So I think we're safe for the future too.
The JSOG javascript code is for production use, so no, it will not be given an unnecessarily complex and inefficient algorithm. There are plenty of code examples in several different languages, including one (Python) that has unordered dictionaries. Anyone should be able to work this out. Sorry.
Moody Salem
Okay, then your documentation needs to be fixed to indicate that JSOG relies on the REFs appearing in order. And this line in particular is incorrect, "JSOG is 100% JSON. No special parser is necessary." JSOG is not JSON, it's an enhancement on the spec because the parsers make assumptions that are not true of JSON. Oh and all those people that are agreeing on the reasonable constraint that you should not program based on unstable assumptions are also wrong and you should collect your upvotes. Not to sound rude but I don't think this is at all unreasonable
Also younare relying on
Also you are relying on the JSON parser to preserve key order, and a quick Google shows that is not consistent where poly fills are used
A library for production use shouldn't have such a glaring issue-you can create "valid JSOG" according to the README and have the parser choke on it because it wasn't created by the generator you provide
Moody Salem
I will fork it and write the implementation for the general case
Jeff Schnitzer
If you can find a single platform on which this javascript code fails, I will take this concern seriously.
felipe ieder
Hi mrs
Hi!! Just a question. Does it exist an implementation in PHP ?
Jeff Schnitzer
I don't know of any. However, take a look at the existing implementations - JSOG is really simple, it should be very easy ot create a PHP implementation. If you do (and put it on github or whatnot) I'll link to it from the JSOG website.
Ok! Thank you! I will let you now if I do it in PHP