From: Brian I. <in...@tt...> - 2004-09-02 22:09:43
|
On 02/09/04 14:21 -0600, why the lucky stiff wrote: > Oren Ben-Kiki wrote: > > >- Clark's 4th pass proposal is accepted. This means that any document with > >old-style tags needs to be converted. Luckily, this is easy enough to do > >using a "sed" script or the equivalent. Also, all old-style tags become > >private tags - hence the application is free to do whatever it wants with > >them, specifically it is within its rights to apply the old semantics to > >them. > > > > > Slick, good work to COB. > > Upon reading an old document, do I: > * Throw an error with a helpful reply about how to convert the document. > * Issue a deprecation warning, allow parsing to continue, and ensure > that all documents are emitted properly. My first bit of advice is to wait two weeks before writing any code. (You never know with these pranksters ;) So one thing that is kind of cool with the new proposal is that old tags like: !okay/news/^feed are now just private types. Any tag without a '|' in it is private. Of course, that's not perfect because: !^feed is another completely different tag. Well at least they are both still valid. So within your application you can have a mode that "does the right thing" and converts the tags to be the same. But yes, this is deprecated and you should not be emitting it in the future. What you want to do for loading is up to you. I would suggest deprecation for 6 months to a year, then throw an error. --- I really like the new proposal. It took me a little time to rewire my head on the issue of private types. My main use case is YAML.pm for Perl related tasks. In the past, I never really thought of private types as useful. They were just this thing you used if you were really on the fringe. But now private types are what YAML.pm will be using all the time. And the tags that YAML.pm currently uses will all be valid, and will remain. They will just be considered private. The main use case of Perl serializers is to write memory to disk (or something else) and read it back in. This can be uses to good effect for myriad programming problems. When doing that, I don't want to be burdened with the thought of global uniqueness. Everything is by its very nature already globally unique because I'm talking to myself. I'm in my own universe. I'm 'private' so to speak. So all my tags are private. --- foo: !int seven bar: !perl/Bar::Bar [1, 2, 3] baz: !typeglob {package: main, name: xyz} bew: !ref {=: *3} All these types are private to the task of Perl serialization and deserialization. '!int' is not a yaml int. It's a Perl int. This is contrived since there is no such thing in practice. perl/Bar::Bar is the tag for standard automatic object serialization. typeglob and ref are two common Perl internal data structures. They have no parallels in other languages. Now if I want to send this document to Python, several situations arise. It all depends on *what* I want to do. If the Python is just a passthru, it should round trip everything so no prob. If I really was sending a message to Python that I wanted it to make use of and send a different response, that's when global uniqueness comes into play. I would probably sit down with the Python person and agree on our "schema" and such. And we'd start using %TAG and such. Because now we are stepping outside the realm of private serialization. It makes sense to get a little more formal. --- Now in terms of private types like: --- a: !int 42 b: !str foo c: !date 03/25/64 It makes a lot of sense for loaders to use the yaml type repository semantics, but it isn't mandatory until you add a --- %TAG:yaml.org,2002: to your document. But the nice thing is that when do add that directive, if you played nice with the private types up front, you won't have to change your document at all Of course, this leaves you with the problem of: --- a: !int 42 b: !ref {=: *3} When these are private types, there is no problem. When I globalize, something has to give: --- %TAG:yaml.org,2002: %TAG:perl.org,1995:types|perl a: !int 42 b: !perl|ref {=: *3} I can only have one blank prefix. I could have assigned it to int or ref. It would probably depend on which one I had more of. This is a weak example anyway. Why would I be wanting to share Perl references in practice? --- I hope this helps clarify our new direction. Cheers, Brian |