RE: [Yaml-core] Two questions

[Oren Ben-K. <or...@ri...>]

Brian Ingerson wrote:
> > | - We need an approach for enumerated types... 
> > |   and if we do have one, why not apply it
> > |   to booleans?
> > 
> > Hmm.  For readability a nice way to do enumerations
> > would be very neat.
> > 
> > | caching: *true
> > | caching: &true

My mistake: these can't be used (reference/alias).

> > | caching: ~true
> > | caching: |true
> > | caching: !true

> All these require at least some lookahead to work. I would argue that
> '|' and '~' are ok. '~true' especially. it could never mean null, and
> you'd need to regex at least 2 bytes into the token anyway.

Right. ~true doesn't look too good, however.

> > | caching: %true
> > | caching: $true
> > | caching: @true
> > 
> > These are probably too close to Perl's abbreviations.
> 
> Plus they are butt ugly for this context.

Right.

> > | caching: ?true
> > | caching: :true
> > 
> > The colon and question already have other meanings.

Actually, no. That is, question mark does (my mistake again), but ':'
doesn't. ':true' is a valid simple value because there's no space after the
':'. And ':true' seems the nicest, visually.

BTW, examining production 168 again I think there's a minor bug in it...

> > | caching: =true
> > | caching: \true
> > | caching: ^true
> > 
> > Perhaps.

If I had to choose from these three I'd probably go for '=true'. I think it
is less friendly than ':true' however.

> > | caching: :true   # I'd rather have this in my config file
> > | caching: !bool 1 # than this. Don't you agree?
> > 
> > Hmm. I think the latter is more clear.

A matter of taste, I suppose... !int 12 is also more clear than a plain 12,
but I'd rather have the plain 12 in my file.

> Um, why are we having this discussion at this point anyway? I can count
> on zero hands how many fully compliant and funtional implementations
> exist today.

Because I want to know whether to add !bool to the spec... what formats to
use.

> I disagree with its usefullness, at least from the Perl side of the 
> world. Perl has no native representation for boolean so YNY round 
> tripping it will make it somewhat useless. Dates and Times at least 
> have classes to transfer into the native model with. As far as I know,
> there is no Boolean.pm class. 

Perl isn't everything...

And even if we are just thinking aboute Perl, boolean is heavily used in
some form or the other in configuration files etc. I'm worried about
everybody rolling his own boolean type. I can see lot of ways one could
"reasonably" do it, even in Perl: one application will use empty vs.
non-empty string, another 0 vs. non-zero integer, yet another using null and
non-null... people may even end up defining their own private/public bool
type. Ugh.

This might be interoperable to some extent in Perl. But trying to move
beyond Perl (even just to YPATH) would become a major PITA.

As for a native perl representation for YNY, why don't you just bless the
scalars 0 and 1? This seems to be enough to do the trick.

Have fun,

    Oren Ben-Kiki