Re: Equality of YAML nodes

Osamu, Oren:


If I can butt in for a moment... I've been listening to the two of you
discuss the equality of YAML nodes and I'm impressed by the understanding
each of you has of computer science. In the "science" of computers, I'm not
equal to either of you, but as I finally got the chance to really sit down
with your last post Osamu, it seems to me that the key question being asked
is about the purpose of YAML.

At one point Osamu gives an example in which you must tag every map as being
a Ruby hash. If I understand correctly, this is to obtain Ruby style
equality semantics. This raises a much simpler question about the intent of
YAML. The question is, is the purpose of YAML to represent native data
structures in an easily readable format or to provide a portable way of
storing the information within those structures? If the former is the case,
then having identical semantics to the native structures used by programming
languages is of greater importance. If the later is the case, then
maintaining consistency within an intermediary format (the YAML data types)
is more important.

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.

I'd love to hear what each of you has to say on this. As well as others. ^-^


Thanks,

BlueG


------------------------------------------------------------------------------
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