From: Clark C . E. <cc...@cl...> - 2002-05-02 23:09:48
|
On Thu, May 02, 2002 at 03:25:36PM -0700, Neil Watkiss wrote: | > --- !seq --- | > 0: one - one | > 1: two - two | | I've always assumed that these would be loaded into memory | in the same way for Perl. Right. This is our classic example (and the one which I based the current information model on, which does not preserve keyed vs series). | Perl has an internal limit of 32-bits for its array indices (even on 64-bit | machines). This sequence cannot be loaded as an array, but it's a perfectly | valid hash. Again, I assumed it would be okay to load it into a | "YAML::SparseArray" object which emulates the behaviour of a Perl array. | Of course, on the way _out_ again, YAML::SparseArray would serialize itself | using the keyed style, since that just makes more sense. Yes. This would be perfectly ok, as when it is written back out, the special "YAML::SparseArray" wouldn't be serialized as the family. Thus, it is only there for round-tripping. | That implies you get Parse/Load/Dump/Emit artifacts. Sometimes | nodes are round-tripped verbatim, and sometimes they arent. Like this: | | --- !seq --- | 0: one => - one | 1: two - two | | --- !seq --- !seq | 0: one => 0: one | 4294967296: two => 4294967296: two Exactly, this would imply that the form is "syntax sugar". Much like the following... --- !int|hex 0x0D => --- 13 | And we all agree that they *should* be different in the tree model, right? I think so. | > Now, the question is, does the distinction exist in the graph | > (native) model? If both of the two above result in the same | > native binding, then the answer should be no. Thus, they are | > distinct up-to, but _not_ including the graph model. | | Right ... we agree modulo the exceptions I mentioned above, I think. Yep. | Now I have a question -- it seems to *me* that the only difference between a | "real" native Perl array and a "support" YAML::SparseArray is that the latter | exists only because of limitations in Perl's implementation. That the memory | image of the two differ does not break YAML compatibility, does it? To a Perl | "user", the two can be used interchangeably: No, this should be just fine. As the distinction is only there due to a limitation and not due to a "syntax sugar" construct which is in the syntax model and not in the graph model (such as building a different object type based on the format). | > As long as he follows the model we agree upon, this is fine. | > However, if his binding uses information which is not in the | > graph model, then his binding is _not_ YAML. | | What does this mean? The only information available to a Loader is whatever | is coming in through the *parser* -- an embodiment of the tree model, right? Right. And there is more information in the tree model than what should be used to construct the native represenation. For example, the order of the map pairs is provided by the loader, but is not significant. Further, the format is available for leaf nodes. The loader should only use the format to construct a native type, but should not choose which native type to use based on the format... The question on the table is if the distinction between the keyed and series is also information which the loader should use. There isn't a right answer, the only concern is that we are consistent across our implementations for the best interoperability. | Or am I confused? I think you got it. ;) | I'll see what responses I get, and go home and read over your previous post | more carefully before answering it. Now I think I'm confused over the graph | model (I thought I knew this :). The graph model is the in-memory structure | of the YAML stream, isn't it? Yep. It models the in-memory (native) structure created by the stream. It describes what sorts of information can be stored in YAML and expected to round-trip between different applications. ;) Clark |