From: Osamu T. <os...@bi...> - 2009-09-22 04:38:42
|
Hi all, I want to complement my post on the other day. >> Note that, as seen above, constructing a ruby's hash or an >> instance of Test class from a YAML mapping node did not preserve >> the data equality. > > In order for YAML to work, the representation of the object to YAML must > follow YAML's rules. The representation of "Test" objects as YAML did > _not_ follow these rules. The author of the Test class should have > overriden the default serialization-to-YAML to resolve it. As long as he > hasn't, he has a bug, and this isn't YAML's fault. Since we are talking about modifying current YAML, it can not be an answer for my question to say "this is the YAML's rule". ;) So, let me discuss whether changing the rules is beneficial for the users or not at all. :( I already gave a feedback to your question how a value-oriented languages should treat ruby's Test object. But I'm afraid that was not selfcontaining enough. In my opinion, to have a specific YAML document really portable between environements, we must have some schema that describe the structure and the meaning of the nodes. So, there won't be a perfect portability without any pre-exchange of knowledge between the serializer and the deserializer. For languages such as ruby and C#, which provides access to the language's meta data, the definition of a class can be a useful schema of a YAML document. Imagine we are serializing an instance of a class SomeClass in C#. public class SomeClass { public int a = 1; public string b = "1"; public double c = 1; public Point3D p; public utf8u[] texts; bool Equals(object obj) { ... # specify how to compare SomeClass objects } } ... SomeClass obj = GetSomeClassInstanceWithMeaningfulContent(); string yaml = YAML.Serialize(obj); The resulting YAML document will be like the next. %YAML 1.2 --- !SomeClass a: 1 b: 1 # I prefered to have this as "1" for the readability, though. c: 1 p: X: 3 Y: 4 Z: 2.1 texts: - "..." - "..." - "..." - "..." - "..." Note that we do not have to go the next way. %YAML 1.2 --- !SomeClass a: 1 b: "1" # By default, 1 is resolved to !!int 1 c: !!float 1 # By default, 1 is resolved to !!int 1 p: !Point3D X: !!float 3 "Y": !!float 4 # By default, Y is resolved to !!bool true Z: 2.1 texts: - !!utf8u "..." - !!utf8u "..." - !!utf8u "..." - !!utf8u "..." - !!utf8u "..." We can resolve the tags for the child nodes from the definition of SomeClass automatically. I undestood YAML allow this, from the description that the tag resolution can be dependent on the path leading from the root to the node. Note that the meaning of each field must be also exchanged in the form of SomeClass's specification between the serializer and the deserializer, to interplete the contents of the fields correctly when deserializing. With languages that provides the access to the class metadata, a general purpose library can be build, which converts native objects of arbitrary classes like SomeClass into YAML document, with refering to the language's metadata database, without having any other explicit schema. Note that both the serializer and deserializer must know the definition of nodes' content, anyway, to interprete the conceptual meaning of each field. Using the definition of SomeClass for that purpose does not seem to weaken the document's portability. I think exchanging the information, how an instance of SomeClass should be evaluated its equality, between the serializer and the deserializer also does not weaken the portability. The way of comparison is often defined as the member function of the class, for example, Equals for C# objects and == for ruby objects. This was the reason why I defined the equality of YAML nodes with non standard YAML tags as: If the nodes are identical, they are equal. If the nodes have different tags, they are not equal. Otherwise, the result is dependent on the native objects' equality evaluator. Do not think this makes the YAML language dependent on a specific language. It merely makes the YAML language dependent on the schema of data. I guess it makes the YAML language applicable to wider variation of schemas of data. > We'd rather not go down this road. The use case you demonstrated (using > "Test" instances as keys) is pathological; I would be greatly suspicious > of a system that used such a method, and I definitely wouldn't want to > bend YAML out of shape to handle it. I hope you understood the concept of my President-Party example. If you think it is still useless, please give some response on it. Thank you, Osamu TAKEUCHI |