Re: [Yaml-core] edict

[Clark C . E. <cc...@cl...>]

On Sat, May 04, 2002 at 07:09:04AM -0400, Oren Ben-Kiki wrote:
| | 4. We drop !map, !seq and !str and allow for empty transfer.
| 
| I want to be able to have a unique explicit transfer URI for each and every
| node, such that strcmp on the transfer would work. The above kills this
| property, replacing it by some magical empty string which can mean any of
| three different things. Ugh.

It means that the unique classification of a node is defined by a 
tuple (kind,family) where kind is in ('scalar','map','sequence') and
family is a uri string.   Up till a few days ago, I had the 
funny idea that the classififcation of the node was exactly the node's
family.   This was incorrect since a scalar with a family of "!!yahoo"
is a different node than a collection with a family of "!!yahoo".
Now that we extend kind to replace collection with map and sequence
it becomes clear to me that this illusion has to go away.

--- !perl/Foo::Bar []

For example, you can't uniquely determine the above node's classification
by just the family; the fact that it is a sequence is also needed.  Thus,
the classification of node above is ('perl/Foo::Bar','sequence').  Once 
you look at it this way, allowing the family to be NULL doesn't hurt 
things at all, in fact it probably makes them a bit cleaner.

| Why do we need this? Well, try writing the following otherwise:
|
| "All '!map' nodes are keyed collection nodes, but not all keyed collection
| nodes are '!map' nodes. For example, a keyed collection node may be a
| '!perl/Foo::Bar' node."

Hmm.  The problem with the answer above is that a "perl/Foo::Bar"
node does not unqiquely label the node, I also need to know if it
is a keyed, series, or scalar.  Thus, since kind is othogonal to
family in this way; I see no harm in allowing family to be NULL.

Further, at an implemetation level, it is a pain to toss around a 
bunch of "!map", "!seq" and "!str" identifiers; I'd much rather have
them NULL (and then use the node's kind) rather than trying to do a
string comparison all of the time...  In effect, think of NULL kind
as the "default" family for a given kind; then we apply other kinds
on an exception basis...

Best,

Clark