You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This didn't pass through to php-internals, but it's somewhat off-topic for the PHP7 jsond RFC discussion anyway. → It's more of a feature-feasibility inquiry.
Is jsond extensible enough to somewhen support JSOL besides standard JSON?
"JSOL" is somewhat of a catchy but not widely agreed-on term. Simply meaning JavaScript Object Literals. The primary difference to JSON being unquoted object keys.
Supporting it obviously comes with the danger of encouraging its use over proper JSON. However it just happens to exist and persist in the wild. And a lot of quirky PHP userland workarounds have been concocted already to utilize it (same goes for Ruby, Python, and JavaScript of course). Just a few easy-to-google samples:
And PEAR::Services_JSON being one of the few proper implementations with optional support for literals.
Clearly there shouldn't be json_encode() support for "JSOL". But something like a JSON_PARSE_LITERALS flag for the decoder might be desirable at some point.
Your lexing and parser tables look really tidy. So would supporting this optionally be possible at all - without harming jsonds` performance advantage in general?
The text was updated successfully, but these errors were encountered:
I have been already thinking about this before. As you say that would have to be added as a non-default feature only. However it's not a priority at the moment but I might try it later and possibly do an RFC. I'll leave this issue open and update it if I do some work on it... ;)
This didn't pass through to php-internals, but it's somewhat off-topic for the PHP7 jsond RFC discussion anyway. → It's more of a feature-feasibility inquiry.
Is
jsond
extensible enough to somewhen support JSOL besides standard JSON?"JSOL" is somewhat of a catchy but not widely agreed-on term. Simply meaning JavaScript Object Literals. The primary difference to JSON being unquoted object keys.
Supporting it obviously comes with the danger of encouraging its use over proper JSON. However it just happens to exist and persist in the wild. And a lot of quirky PHP userland workarounds have been concocted already to utilize it (same goes for Ruby, Python, and JavaScript of course). Just a few easy-to-google samples:
PEAR::Services_JSON
being one of the few proper implementations with optional support for literals.Clearly there shouldn't be json_encode() support for "JSOL". But something like a
JSON_PARSE_LITERALS
flag for the decoder might be desirable at some point.Your lexing and parser tables look really tidy. So would supporting this optionally be possible at all - without harming jsonds` performance advantage in general?
The text was updated successfully, but these errors were encountered: