RE: [Yaml-core] RE: Proposed Changes to YAML by example

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

Brian wrote:
> Here is my view of how and where things happen.
> 
> For loading YAML:

+1

> For dumping to YAML:

+1

> Doing things this way, lets you hook a parser to a emitter 
> with no loader or dumper involved. It is a clean separation 
> of concepts.

+1

> No. You're not getting it. Booleans, prices, whatever get 
> loaded into objects. Then I can key off the object class to 
> determine what to do.

Hmmm. I'm uncomfortable with loading a Boolean to a Perl object. I sort
of assumed it is best to load booleans to '' and 1 (and shadow them as
Booleans). Can I still simply write ``if($foo)'' if the value of
``$foo'' is (a reference to) an object of type Boolean? At any rate...

> But the Perl SV is a different animal. It's three types in 
> one, and you can't tell it's state without going to C. And 
> even if you go to C and find out, you have to *assume* that 
> since the application last used this value as a string, then 
> it was meant to be *typed* as a string.

I see where you are going with this. It actually fits neatly with the
load/dump process you described. By default, you use the YAML::PerlSV
"casting class", and only this class. It makes use of the Perl SV
information to load/dump things as str/int/float, and is good enough
"out of the box" for most Perl applications. If I specify my own
"casting classes", they would be tested before YAML::PerlSV. Only if
none of them match then YAML::PerlSV will be used.

> And I'm not sure that boiling everything down to 3 use cases 
> today, is really worth the cycles. Let's just see what use 
> cases arise.

The above is powerful enough to allow for every imaginable behavior,
assuming the existence of appropriate additional "casting classes".
Specifically, if there exist YAML::int, YAML::float, YAML::str (matches
everything), YAML::plain (likewise) and YAML::noimplicit (matches
everything and complains bitterly about it), then I can construct all of
my three use cases and many more.

Neat.

Have fun,

	Oren Ben-Kiki