Re: Yayson (proposal for a YAML presentation embedded within JSON for browser clients)
Matthew Willson <[email protected]>
| Newsgroups | gmane.text.yaml.general |
|---|---|
| Message-ID | <[email protected]> |
> I wouldn't design a language based on a premature optimization of an implementation detail. With all the code needed to make a JSYNC implementation, I doubt that detail would make any noticeable difference. ... > If this causes more mallocs, you can throw out any savings you _might_ get avoiding a regexp. On the other hand, with languages like javascript with immutable strings, you have to malloc more strings as a result of any regexp matches. But yes you may have a point there. Would have to measure to tell for sure and would probably depend on the shape of the data. I don't think trying to optimise this (whether for parsing speed, or for size in memory, or size on the wire) is premature though. At least for me, the only reason I'm considering a somewhat hacky embedding like this is because I'm running under performance constraints in a somewhat limiting environment, and want to leverage the fast native JSON parser available in that environment to the maximum extent possible when it comes to deserializing YAML data. Arguments about elegance seem a bit besides the point---while neither of them look awful, this is going to be a somewhat clunky syntax hack at best IMO, that's just the nature of it. Personally I felt mine was slightly more straightforward on the syntax front if more verbose, but I'm not too bothered either way. > The above is valid YAML[1], so effectively you are defining another subset of YAML. I would advise against this. Other people have defined non standard subsets of YAML, in the name of simplicity. (YAML::Tiny in Perl). I think this just muddies the waters, and confuses people. It would be better to get all the YAML implementations working properly and in harmony, with similar APIs. I think JSYNC, would facilitate that. Fair enough. Although I think the complexity of YAML syntax is a problem (of which JSYNC is one symptom), and so some standardised subset of the syntax which enables the full semantics would be nice. If others have already managed to 'muddy the waters' when it comes to standardising this, that's too bad. Anyway will be interested to see the spec for JSYNC when it arrives; perhaps at that point I'll have a go at benchmarking a javascript implementation against the simpler (but less general) approach which we're using at the moment. -Matt ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo