On Friday 14 March 2003 02:54 pm, Brian Ingerson wrote:
>
> So how do you think that specific type handling is going to be
> cross-language? If you can fully load a !foo {} from Syck, there's a
> problem. Because it assuredly won't work from perl. Your syck node
> should contain a kind and a type. And the program using Syck should call
> the class method to create the foo object.
>

A SyckNode does include a kind and type.

  [from syck.h]
  struct _syck_node {
    // Symbol table ID
    SYMID id; 
    // Underlying kind
    enum syck_kind_tag kind;
    // Fully qualified tag-uri for type
    char *type_id;
    // Anchor name
    char *anchor;
    union { ... } data;
  }

If implicits are turned on then only the types from the central repository are 
tagged.

  - [ "12", ! "12", !foo "12" ]

In the above example, you'd have both scalar nodes listed as kind 
`syck_str_kind'.  The nodes would be typed `tag:yaml.org,2002:str', 
`tag:yaml.org,2002:int' and `tag:yaml.org,2002:foo', respectively.  It's an 
optimization.

One of the bottlenecks in YAML.rb has been using regular expressions to detect 
implicits.

> I would argue against putting Ruby only features in Syck. Put those in a
> separate C library.

Absolutely.  I have wondered about the possibility of having !syck/* types, 
though.  A user recently asked if Ruby symbols could be added to the central 
type repository.  I don't know if symbols belong in the central type 
repository or in a repository shared by languages who use a similiar loader.

> Actually I do things a bit differently in Perl. A YAML::Parser is
> definitely not a subclass of YAML::Loader. A Loader object contains a
> parser object, which keeps them totally orthoganal.

Hmm.  Hmmmm.  I'll think about this.  I can see the advantages.  My loader 
classes are just shells that farm the loading off to callbacks registered by 
the user.  I don't know what the implications are of having the loader become 
so easily decoupled.  If a user changes the loader, then who knows how 
documents would be loaded.  I guess that's the idea but I can see it being 
the source of bugs.

  require 'yaml'  # Defaults to YAML::Loader::Syck
  require 'okay/rpc'
  require 'jackslib'   # Switches to YAML::Loader::Jacks 
                       # for a spell.

  # Are the !okay/rpc types registered with Jack's loader?
  orc = Okay::RPC::Client.new( 'whytheluckystiff.net', '/okayRpc/' )
  p orc.call( 'system.listMethods' )

  # User emails why...

I'd prefer it if Jack subclassed the YAML::Parser and used his loader class 
directly rather than affecting the loading of YAML throughout the system.  I 
can see wanting to switch loaders out (Syck, libyaml, pure Ruby).

Anyway, you're a BDUFer and bless you for it, BI.  I'm a 
see-you-at-the-finish-liner.

This kid just walked into the room with a tae-kwon-do outfit.  I'm going to 
see what he wants.

_why