From: Oren Ben-K. <or...@be...> - 2004-02-27 23:05:20
|
Brian wrote: > So the default behavior of YAML.pm (the new upcoming one) > will be to load everything as a string. ie No tag resolution > (other than defaulting to !str). OK. > Beyond that, users will be able to specify classes that > affect type resolution. For example if a use just says: > > use YAML; > use YAML::int; > > They will get integer tag resolution. Not that this would > really be useful in a pure Perl application. But it would (should) be useful for round-tripping... See below. > Now in Python, using a string as a number would raise an exception. > > So there is this problem. If Python passes Perl this: > > --- > int: 12 > string: '13' > > And Perl has integer resolution turned on, it will still dump > the loaded document like this: > > --- > int: 12 > string: 13 -1. IMVHO, if a user of YAML.pm chooses to "use YAML::int", this should affect both input *and* output. That is to say, it should cause YAML.pm to not emit in the plain style anything that would be misinterpreted as an integer (and, of course, it should emit all integers as plain scalars). Otherwise, YAML.pm isn't consistent with *itself* - doing either YNY or NYN round-tripping will fail. > The only way out is to turn on a shadowing feature that keeps > track of plain vs nonplain. This wouldn't really work though > if the scalar value was changed and the shadow lost. Isn't this exactly what "use YAML::int" does? Somehow marking some nodes as "integers" while others are "just strings"? Understandably, if the program modifies the data, it is also its responsibility to modify this shadowing/meta-data. If you want to mess with a cave drawing, you have use charcoal and get your hands dirty :-) > It seems that the Perl application would have to have code > that kept the python schema intact. ie The programmer would > have to know the schema and write it up in Perl code. It doesn't have to be a specific schema, actually. You might allow for something like "use YAML::Common" which would load "common" types - integer, float, Boolean, date... > So there's no magic bullet for cross language sharing. > Schemas will indeed be important in this use case. Having a "common" set of types would do wonders for cross-language compatibility. Of course you'd also have to allow an easy way for an application to construct and manipulate such "cave drawings" directly, in addition for allowing them to be loaded from and dumped to YAML. Have fun, Oren Ben-Kiki |