From: BlueGM <bl...@gm...> - 2009-09-20 19:31:27
|
> -----Original Message----- > From: Oren Ben-Kiki [mailto:or...@be...] > Sent: Sunday, September 20, 2009 2:22 PM > Subject: RE: [Yaml-core] Equality of YAML nodes > > On Sun, 2009-09-20 at 11:34 -0400, BlueGM wrote: <omitted the text Oren was responding to> > 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. If that's the intent, then I agree that points 2 and 3 should be reversed. And perhaps point 2 (what would become point 3) should be reworded slightly to emphasize its "likeness" to those native data types rather than leaving it open to interpretation as to whether it means "like" or "exactly matches". Which then leaves the question of, does this narrow the application of YAML, as Osamu states when he writes: "I agree that the way you go is completely selfconsistent and theoretically very smart. But I feel it narrowers the application of YAML." And, with that, if it does narrow the application of YAML, how great of a concern is it? On that, I imagine there will be a great difference of opinion. My own opinion is that while it may make YAML a little harder to use in some cases (certainly, some other recent conversations relate to problems of the differences between the native representation of data and their YAML representation), it doesn't actually prevent YAML's use in those cases and widens its potential use in cases where systems must communicate cross platform or language, which could be exceedingly difficult and, in some cases, even impossible otherwise. In other words, I see the value of portability as much greater than the extra cost of YAML not always perfectly matching the definitions used by languages. I also see the cost of not having that portability on applications that require it to be much greater than the cost to applications that have to deal with differences in the definitions of the types used (including their equality). This becomes notable, by way of example, in the oft cited case of a YAML editor, which will quite frequently be in a different language than the language that the data in the YAML file will be used for. Of course, this is largely a theoretical discussion anyways. As Osamu quite effectively points out, existing libraries don't implement the YAML specification perfectly. That's hardly new, or unique to YAML, though. It's the real culprit behind cross platform incompatibility in more than a few public standards. Those, of course, are my thoughts. I'd be interested in hearing what others have to say about this too. As I said, it is largely a question of opinion (being a cost/value estimate of each). Thanks, BlueG P.S. The yaml-core mailing list hasn't yet forwarded the message that Oren was replying to, so it might be out of sequence with this message, assuming it makes it through at all =p. If it doesn't I'll resend that message to the list later. |