Re: Next YAML: drop equality definition

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


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