Would you store configuration data in a .java class? This is the same case.
http://stackoverflow.com/questions/18255226/storing-configuration-data-json Use yaml, properties, ini, xml or your own format, but please, don't use json or javascript files... People like comments. If I remember correctly, someone said that json was choosen to save the metadata file (package.json) because there were no good alternatives. El jueves, 6 de febrero de 2014 08:17:38 UTC+1, George Snelling escribió: > > Alex, > > We just say > > config = require('./config.js') > > where config.js exports a plain old javascript object. > > I think this solves both beefs you have with json: comments and trailing > commas. > > Admittedly this approach suffers the keyword problem: if you name any of > your config keys javascript reserved words you may die a puzzling death. > By convention we don't do that. > > Perhaps yaml is more elegant and powerful, but exporting plain old > javascript objects for config works fine for us. > > Regards, > > -George > > On Wednesday, February 5, 2014 4:37:22 AM UTC-8, Alex Kocharin wrote: >> >> >> 05.02.2014, 15:47, "zladuric" <zlad...@gmail.com>: >> >> >> >> On Tuesday, February 4, 2014 2:43:25 PM UTC+1, Alex Kocharin wrote: >> >> >> 04.02.2014, 17:01, "Oleg Slobodskoi" <ole...@googlemail.com>: >> >> Am 04.02.2014 um 13:46 schrieb Alex Kocharin <al...@kocharin.ru>: >> >> 1. Why JSON? This format was created for data serialization, and isn't >> suited for maintaining by humans. >> >> We could support cjson (https://github.com/kof/node-cjson) or yml ... >> but I am not sure that json is an issue here. I personally had never a need >> to use something more expressive in this case, but I am open for it. >> >> YAML of course. It's the most sensible general purpose format used for >> config files (unless your tool is able to change that config on the fly in >> which case the issue starts to be complicated). >> >> >> >> Out of curiosity, where can one get informed on these things? >> >> Personally, I prefer json over yml. That way I never leave JavaScript way >> of thinking and encapsulating things. But I don't do all that much >> configuration, it's generally customizing pregenerated config files. I >> rarely produce packages, I mostly consume them. >> >> >> If you prefer json over yaml syntax, switch to json5 instead. It solves >> most of the json issues, keeping common syntax the same. I didn't mention >> that because it's not yet a standard, but I hope it'll be soon. >> >> For config files there are exactly two issues with json: >> >> 1. doesn't support comments >> 2. doesn't support trailing commas >> >> Here are a few examples I started to collect recently, you can see for >> yourself: >> >> https://github.com/rlidwka/yapm/blob/master/changes/package-yaml.md#a-few-examples-why-you-should-not-use-packagejson >> >> Apart from comments, there are quite a few quirks there. Did you know >> that JSON is not a subset of javascript? It creates a handful of issues as >> well. I love it how \t, \b and other escape characters are supported, but >> \v don't. And as everyone knows already, JSON isn't extendible and doesn't >> support dates. Remember escaping "\/" and that history of how ASP packed >> Dates? That was funny indeed. >> >> There are good parts in there too. For example, LDJSON is generally a >> very good idea, and used wisely. >> >> YAML has its share of issues of course. It doesn't support tabs for >> indentation (pretty stupid decision imho), has no block comments, and it's >> hard to update it from an application without changing it's formatting. >> >> There is no ideal data format you know. Each one of them is used for >> different things. JSON is good for what it does (it's client-server data >> exchange). But unfortunately it's too easy to use (how do you like that you >> can do require('./something.json'), but require('./something.yaml') is >> officially deprecated?), so people misuse it quite widely. :( >> >> >> >> >> -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
