From: Oren Ben-K. <or...@ri...> - 2002-06-07 19:10:05
|
Rolf Veen wrote: > > I call on the expertise of the list: How > > does this work out for the various languages? > > In Java you have Object.hashCode(). From the API documentation: ... and in C you have memory addresses, in OODBs there's a unique OID, and so on. But that's only half the issue. The thing is that in order to do a one-pass output you'll have to attach an anchor for *everything*, just in case. That's rather ugly (though it is allowed). There's no perfect solution, I'm afraid. We probably could have gone with a mechanism that allows data to be easily written one-pass. However, any such mechanism would cause a one-pass *reading* of the data to be imposible. There is a sort of "conservation law" involved. We've decided to go with easy one-pass reading and harder one-pass writing, because: - Data is read more times than it is written (almost by definition). - The writer of the data typically has more control. Some (most?) native data structures are random-access, allowing two-pass, while YAML text is harder to access randomly. - The writer also has more knowledge of the situation. For example, a one-pass is OK is you know there are no references. Or maybe you know certain types aren't referenced while others are, or certain areas in the data, or whatever. - Finally, the anchor mechanism is simplest the way it is. KISS. I think this is an important decision and the right one. As an aside, I can mention XSLT, which IMVHO has chosen the wrong way of processing the data (one pass on *output* instead of one pass on *input*). Yes, they have some theoretical benefits from their approach, but I haven't seen them resulting in practical benefits (then again, I'm not that up-to-date on XSLT processors). I believe an approach more similar to M4's (one-pass-on-input macro processor) would have made more sense, and when we get around to defining YTL I'll be pushing for such an approach. Have fun, Oren Ben-Kiki |