From: Clark C . E. <cc...@cl...> - 2001-06-14 13:54:15
|
On Tue, Jun 12, 2001 at 04:28:48PM +0200, Oren Ben-Kiki wrote: | Clark wanted to be able to evolve a scalar to a list, and Brian's and my | objection to this was that most of the time we'd want a list to map to a | normal native list (which doesn't support the "have a default value" | behavior). This objection can be overcome by somehow annotating such lists | in a special way, e.g.: | | address: First address | | Evolves to: | | address: @= | First address | Additional address This as opposed to? address: @ First address Additional address I am curious what the difference between these would be? I was assuming that a asScalar() when called on the "@" node would return the first value. The asScalar() function would be at the parser level -- and perhaps built in as a external "friend" function that can work on any list or map. Thus... lists and maps load as a lists and maps respectively, unless the consumer asks for a scalar instead. asScalar() is *layered* over the underlying interface and need not be used directly. | Since the file explicitly makes use of the "list with default value" | construct, it is OK if it is implemented less efficiently via some | extension/wrapping to the normal built-in list construct. Thoughts? Hmm. This is interesting. I think I'll need some "implementation experience" before we should move in this direction (and even implementing asScalar... ) Thoughts? Best, Clark |