From: Trans <tra...@gm...> - 2013-02-21 16:47:20
|
On Thu, Feb 21, 2013 at 11:04 AM, Oren Ben-Kiki <or...@be...> wrote: > I'm nervous about the "same object comes in via two different tags" for > several reasons. > > First, an object has only one (full) tag. Of course one can have several > equivalent shorthand which expand to the same tag. > Yes, that *should* be the case. But people fudge. Ruby's Psych implementation recognizes appox. 13 different tags when one defines a single "full" tag. Perfect round-tripping is of course not necessary, but I thought it would be nice if it were at least smart enough to have `document == YAML.dump(YAML.load(document))`, i.e. if you immediately emit what you just loaded it will come out exactly the same, local tags and all. Or is that a bad idea in itself? Should all local tags always become the "one full tag" when emitted? Note, the same goes for decoration. If a !!str, for instance, was loaded using the literal `|` form, it seems like a nice idea to remember that and emit it the same way. > Second, since one either gives a tag or dereferences an anchor but never > both, how do you manage to have "the same object" with two different tags > in the same YAML document? > Less likely to occur in the same document, but it could. For instance, a schema could translate a !!int to an Integer object, but also !number to an Integer object. But Integer is singleton in Ruby, so there is only ever one object for a given number. So if a document has: --- a: !!int 42 b: !number 42 Then how is that going to re-emit? I guess one could just say that's a bad schema, and we can only expect one class to have but one emit tag per schema, regardless of what it might have been loaded in with. That would eliminate the round-tripping portion of my case, at least in so far as the tag goes. Is perfect round tripping simply not something one can expect? > Finally, at least in Ruby, you can get away with a lot if you monkey-patch > either specific objects or even classes, but I hesitate to promote this :-) > > Actually, it's the monkey patching I am trying to avoid. By delegating I can store the tag and decoration used for the loaded node in the delegator, so that re-emission looks the same. If I don't use the delegator, the only way to do this is via monkey-patching --which I too would rather not do. |