Re: [Yaml-core] [ANN] Syck 0.08 -- Next-generation of YAML.rb

[Brian I. <in...@tt...>]

On 14/03/03 15:57 -0700, why the lucky stiff wrote:
> 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.

cool.

>   - [ "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.

Interesting. I wouldn't have guessed this. At least in Perl, regexp
operations are usually close to pure C. Not often the source of
bottlenecks unless the regexps are poorly written.

> 
> > 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.

What are symbols?

I see no reason for not putting lots of types in the repository. That's
what it is there for. The common wisdom is that type checking is done at
the loader level though. If your loader is designed for multiple
inheritance, then you can simply add a new type class as new types are
added, without have to change the parser or core 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).

I am not suggesting that requiring a loader class effect the whole
system. That's ludicrous. Each YAML Load operation is done from a
particular YAML::Loader object. That Loader object may inherit certain
properties (like implicits) from various Loading classes, but it has one
predictable beahviour.

In fact if a load operation involved another load operation (like with
!include processing) then a separate loader object would be used. And
that separate object might be from a completely different class.

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

Silly programmer, there's no basement in the Alamo, er I mean, there's
no finish line.

Anyway, you and I are the only ones currently implementing YAML stuff,
so we really shouldn't fight. It's all about peace and love.

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

KICK HIS ASS.

Cheers, Brian