From: Neil W. <neilw@ActiveState.com> - 2002-03-15 02:10:20
|
Hi all, The spec says we can ignore duplicate map keys with an error. What should happen here? --- #YAML:1.0 foo: bar foo: - &0001 10 bar: *0001 In other words, the parser has ignored the second instance of "foo", so there is no node for "bar" to point to. I suspect the above should be equivalent to this (an error): --- #YAML:1.0 foo: bar bar: *0001 With YAML.pm it's equivalent to the stream below, because Brian stores the anchor even though he doesn't assign the resulting tree to "foo": --- #YAML:1.0 foo: bar bar: 10 If it's a fatal error, the parser can avoid even parsing the second "foo" branch. It knows the value can't be used, so it can skip the entire thing and continue parsing at bar. I suppose it seems like a needless optimization now, but if "foo" were a very large branch, it wouldn't be so insignificant. I suppose there's nothing particular *wrong* about either case, as long as both document their behaviour and generate warnings (YAML.pm does warn about the duplicate key). Is there any reason this shouldn't be a fatal error? And should this be covered in the spec? Later, Neil |
From: Clark C . E. <cc...@cl...> - 2002-03-15 03:33:17
|
| The spec says we can ignore duplicate map keys with an error. Right. This was the case where someone provides a duplicate item in a configuration file by mistake. It can probably just be a fatal error; but I remember some arguments about making it just a "Warning: node ignored beacuse duplicate". Is there a good reason why it is just a warning? Can we make it a fatal error (and thus the contextual item below a non-issue)? | --- #YAML:1.0 | foo: bar | foo: | - &0001 10 | bar: *0001 | | In other words, the parser has ignored the second instance of "foo", so there | is no node for "bar" to point to. I suspect the above should be equivalent to | this (an error): | | --- #YAML:1.0 | foo: bar | bar: *0001 If the skipped node is a warning, then bar would have to be a fatal error... | With YAML.pm it's equivalent to the stream below, because Brian stores the | anchor even though he doesn't assign the resulting tree to "foo": | | --- #YAML:1.0 | foo: bar | bar: 10 I can see this... but it's probably a _bad_ idea this type of behavior could be a hair puller... | I suppose there's nothing particular *wrong* about either case, as long as | both document their behaviour and generate warnings (YAML.pm does warn about | the duplicate key). Is there any reason this shouldn't be a fatal error? And | should this be covered in the spec? I'd prefer to make duplicate nodes fatal; but if they must remain warnings, then it should be clear that their content (and any descendents) must be skipped and not used for any purpose, such as anchors. Also, I hope the spec is clear that a missing anchor is a fatal error. If not, this should be added to. Good catch Neil. Thanks! Clark |