At 04:53 PM 8/2/2001 -0400, Clark C . Evans wrote:
  Why?  Beacuse I'm serializing to/from a database
  all of the time, and my database already has
  primary keys that are *data* and must be part
  of the information stream.  Yet, I'd like to
  use these keys for YAML reference linking... 


Thought #1: You are awesome!

Thought #2: Ugh, please no!

Thought #3: But I really need it!

Thought #4: Sometimes I'll want the keys to be data and accessible to the application, in which case I don't get a graph.  Sometimes I'll want it all hidden from me, in which case I get just the graph.


Thought #153: I'm inclined to solve this problem transparently through the (de)serializer.  The (de)serializer would use type information to decide how to (de)serialize a table record.  One type might be TabularRecord and another TabularNode.  The schema for TabularNode would know that a particular column holds a key that serves as a reference, while the schema for TabularRecord wouldn't assert this (as in the default case).

Hence, the (de)serializer decides whether to take advantage of YAML's reference mechanism.

One strange consequence of this implementation is that table names would actually serialize as type names.  A table would be a typed but unnamed list.  Maybe this isn't so strange, since this is exactly how a database is structured: tables are classes of instances, not instances.

Well, now I firmly understand why YAML must support type annotation.

Reciprocating thoughts?