From: Intransition <transfire@...>
Date: 2010-09-23T01:28:50+09:00
Subject: Re: Ruby-based data language

On Sep 22, 7:20 am, Brian Candler <b.cand...@pobox.com> wrote:
> I'd have said most packages use YAML. If you can provide examples which
> use method_missing and block-based structure just for conveying static
> configuration information, I'd be interested to see them. But then
> that's what you asked for in the first place :-)

I think a Gemfile is a pretty good example --yes you can use
conditional code in these files, but IMO it's bad design.

Also, https://rubygems.org/gems/configuration looks fairly popular and
it is pretty close to what I'm talking about.

> > So the analogy
> > isn't over the data structure, but rather the use of the underlying
> > language as a syntax model.
>
> The difference is that JSON *is* a direct subset of Javascript, and can
> be eval'd directly to give a value.
>
> Let me put it another way. If you were parsing your example:
>
>   name "Joe Foo"
>   age 33
>   contact do
>     email "j...@joefoo.com"
>     phione "555-555-1234"
>   end
>
> would you expect as Hash oas the result?
>
> If yes: then it looks like you're proposing an alternative syntax for
> Hash literals - one which isn't widely used. It's Ruby-inspired but not
> really Ruby, since a simple eval of the above will fail without
> additional supporting code. It would be similar to Builder, but (a)
> creating a Hash as its output instead of XML, and (b) intended for use
> with untrusted inputs, so parsed rather than eval'd.
>
> If no: then what do you expect to get instead? I suppose you could have
> a stream parser API, and trigger start/end actions as you go, but that's
> not a very convenient API for reading a config file.

I would expect to get an object that gave me access to the data. What
kind of object depends on the parser. If only #eval were the parser
and nothing more, I'd expect a method missing error.

I get what you are saying. But even JSON goes through a parser in
Javascript and is not simply evaled, for the same reasons I would like
to see a Ruby-syntax data/config format. And when someone thinks "Ruby-
syntax data/config format" they are thinking builder-style, not hash
literals.