Re: Next YAML: drop equality definition

There is no requirement that early detection catch 100% of the duplicate
keys. There is a requirement that early detection will never incorrectly
flag different keys as being duplicate.

So: A YAML processor _need not_ preserve the identity of scalars. Therefore
it is allowed to (correctly) flag equal scalar keys. Because an application
_must not_ rely on scalar identity to compare scalar keys.

The fact that "1+2i" might be equal to { r: 1, i: 2 } just means that early
detection isn't perfect. Which is OK since the final definitive equality
check is done by the application anyway.

What we really want is to _allow_ YAML processors to flag { a: 1, a : 2 }
as a duplicate key, because this is the most common type of error. The
rules _allow_ early flagging of these errors, without waiting for the
application, and a well-behaved processor _should_ flag this as an error,
as early as the entry to the compose stage.

Oren.


On Fri, Mar 4, 2016 at 9:51 PM, Osamu TAKEUCHI <[email protected]> wrote:

> Oren,
>
> Thank you for your understanding of my poor description.
>
> Note, this only applies to complex keys.
>> The spec clearly says identity is not preserved for scalars.
>>
>
> The exact statement is
>
> > A YAML processor may treat equal scalars as if they were
>> >identical.
>>
>
> So, YAML processor may also preserve scalars' identity.
> Is this true?
>
> Then, this may apply to scalars, too.
>
>
> Actually, As Kirill pointed out, a scalar node could be
> equal to a collection node under a realistic schema as
> below.
>
> x: 1.0i
> y: { re: 0.0, im: 1.0 }
> z: { rho: 1.0, phi: 1.5707963267948966 }
>
> Similarly, a class object that has its string representation
> can also be stored as a scalar node, which may have its own
> weird comparator with customized hash generator. It may be
> an identity-based comparison. It may ignore some fields for
> comparison. If YAML library ignores the native comparator
> for such scalar nodes, users will be surprised.
>
> This is from my experience implementing C# library.
> Many of C# classes have so-called TypeConverter that converts
> the native object to/from its string representation for
> serializing purpose. In such cases, it is natural to store
> such an object in a scalar node in a YAML document, with
> an explicit/implicit tag to represent the data type.
> So, a scalar node with an explicit/implicit tag may
> no more be a simple scalar in the native object form.
>
> It is like:
>
> Greeting:
>   - "Hello world!"
>   - !System.Drawing.Point 100,100
>   - !System.Drawing.Font Times New Roman, 14pt
>
> With such a use case in mind, distinguishing scalar nodes
> from collection nodes in the preservation of identity is
> not natural for me. I prefer to preserve scalars'
> identity in my library and to apply native comparison
> method to both of scalar node and collection node,
> if the YAML spec allows.
>
> I know it is very rare to have such objects as keys
> of a mapping and the definition of equality causes
> any problem. At the same time, I don't see any benefit
> to define objects' equality in YAML spec in different
> manner from the native one.
>
> In my opinion, the definition of equality should belong
> to the domain specific data type, not to the serialization
> language.
>
> Best,
> Osamu Takeuchi
>
>

------------------------------------------------------------------------------

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core