Re: Equality of YAML nodes

On Sun, 2009-09-20 at 11:34 -0400, BlueGM wrote:
> I was asking myself that question and then I looked at the specification, to
> try to understand its goals, and I see the following:
> 
>    The design goals for YAML are, in decreasing priority:
> 
>       1. YAML is easily readable by humans.
>       2. YAML matches the native data structures of agile languages.
>       3. YAML data is portable between programming languages.
>       <more follow>
> 
> So, now I'm wondering... which is really more important to the
> specification? That we perfectly match the native data structures of "agile
> languages" or that the data be portable between languages? It seems to me
> that if point 2 was meant to mean a perfect match to native structures, then
> Osamu is correct in saying that it is necessary to either define equality in
> terms of the native methods of determining such equality or some other
> mechanism (whether a tag or by providing a unique hash) so that the equality
> operator matches the native implementation. If, as seems more likely to me,
> point 2 was meant to imply creating data types that are "like" their native
> counterparts that appear in different languages (so that the native types
> are easily represented in a majority of use cases), then we fall through to
> point 3 where having a consistent definition of the data types (and, by
> extension, their equality) is more important.

Yes, you have hit the nail on the head. I think one the errata we need
to fix to reverse the order between points 2 and 3, to clarify this
point (unless Clark objects).

The point never was to "perfectly" match native data structures. Another
good example of this point (that also triggered a lot of debate at the
time) was PHP's native maps-with-ordered-and-duplicate-keys. YAML's
solution to that is to use a sequence of single key/value pairs, as
in !!omap [ foo: bar, foo: baz ]. The same arguments were raised there
as well as here (for identity): default mapping, matching native data
structures, portability, cleanness of the information model, commonality
of use cases, etc. The decision (there as well as here for identity)
was/is to stick with portability and cleanness of the data and common
uses cases rather than exactly matching a specific programming language
and less common use cases.

Have fun,

    Oren Ben-Kiki


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf