From: Clark C . E. <cc...@cl...> - 2001-06-05 12:15:52
|
On Tue, Jun 05, 2001 at 01:07:16AM -0700, Brian Ingerson wrote: | > Are de-serialized into a YAML-object. That is, *Only* if you | > are actually *using* substitutability, you pay for it (The | > good old C++ notion of "don't use, don't pay"). I was only considering the iterator (parser) interface having this functionality built-in, since the additional overhead is an additional (and rather simple) function that the user of the library can just ignore if they so choose. For language bindings, I was thinking that the asScalar function would be more or less an *external*, or "friend" function, not a method. I was using the method syntax for readability, I had not intended that it actually be a method.... If, for some cases, it can be implemented as a method, well... more power to that language. But I don't think this is at all a requirement, an external function should be just fine, as ugly as it may be. | > That's why I don't like Clark's idea of a list having a | > default value of the first element; it forces one to always | > pay this price, when for most lists it isn't required. I also | > don't think it is useful to evolve a scalar into a list; | > that's not part of the "color" idiom, anyway. I think it may be useful for times when something originally thought to be single value (such as an address) turns out to be multi-valued. If you only allow "extensions" using the map construct, this forces a particular way to extend the scalar (use a map, and then a list) instead of just converting the scalar into a list. I've had this case pop up before... | > Clark? Well, if it seems problematic... I'll compromise here. ;) | Well, I *like* all of this. It's certainly more appealing than what I | had feared. If non-classed structures remain native, we're cooking with | gas! I hope so. Charcol may taste better, but it is very messy. And who likes to chop their own wood? For recreation, yes, but not for daily work! | Clark's idea of having a scalar change to a list, requires that it | actually be neither. It can only be an object. Brian, thank you for working the proposal out.... I was not actually intending this. Although I was thinking of an exteranal "asScalar()" function that returns a scalar when handed a list. Is this possible? | Also, it doesn't seem to make sense that a !Foo could morph | into a !Bar does it. Maybe if !Bar were a subclass...??? Do | we support subclasses? Hmm. Suppose you were expecting... tag: a: "hello" and someone gave you, tag: a: "hello" b: "world" Then the second case is substutable for tag. Hmm. How can this be codified? | > > Perhaps a better alternative is to only provide | > > substitutability within classes. Therefore all | > > classes will be first class YAML classes | > > (round-tripping, substitutable, etc), but regular | > > data will never get upgraded into a class. That way, | > > maps are just maps like before. Hmm. I really like that. | > | > I'm not certain exactly what you mean... I was thinking that the asScalar function is not a method... and thus completely separate from both the native types and classes. I hadn't actually put serious mental energy into thinking how it would work for a given class system. If you *have* a YAML class... then I can see where asScalar() could be a nice method. | I think for once, Oren and I are on the same side of the | fence, and Clark might be on the other. You will find my perspective leans towards the iterator (parser) interface... which is quite a bit different from the native, internal representation. I think we are all on the same side of the fence.... Best, Clark |