From: why t. l. s. <yam...@wh...> - 2003-03-14 22:45:46
|
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 cal= l > 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;=20 // 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 repositor= y are=20 tagged. - [ "12", ! "12", !foo "12" ] In the above example, you'd have both scalar nodes listed as kind=20 `syck_str_kind'. The nodes would be typed `tag:yaml.org,2002:str',=20 `tag:yaml.org,2002:int' and `tag:yaml.org,2002:foo', respectively. It's = an=20 optimization. One of the bottlenecks in YAML.rb has been using regular expressions to d= etect=20 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/* type= s,=20 though. A user recently asked if Ruby symbols could be added to the cent= ral=20 type repository. I don't know if symbols belong in the central type=20 repository or in a repository shared by languages who use a similiar load= er. > 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 loade= r=20 classes are just shells that farm the loading off to callbacks registered= by=20 the user. I don't know what the implications are of having the loader be= come=20 so easily decoupled. If a user changes the loader, then who knows how=20 documents would be loaded. I guess that's the idea but I can see it bein= g=20 the source of bugs. require 'yaml' # Defaults to YAML::Loader::Syck require 'okay/rpc' require 'jackslib' # Switches to YAML::Loader::Jacks=20 # for a spell. # Are the !okay/rpc types registered with Jack's loader? orc =3D 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 cla= ss=20 directly rather than affecting the loading of YAML throughout the system.= I=20 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=20 see-you-at-the-finish-liner. This kid just walked into the room with a tae-kwon-do outfit. I'm going = to=20 see what he wants. _why |