D:YAML 0.3 released

[Kiith-Sa]

torhu wrote:

> On 16.11.2011 21:15, Kiith-Sa wrote:
> ...
>> GitHub: https://github.com/kiith-sa/D-YAML
>> Docs  : dyaml.alwaysdata.net/docs
>>
>> You can get D:YAML 0.3 here: https://github.com/kiith-sa/D-YAML/downloads
>>
> 
> Great, I've been looking into YAML lately.  Would be interesting to see
> how the speed of your library compares to Tango's XML parser.  Maybe
> I'll do some benchmarking.
> 
> I think your API could be simplified in some places.  I rewrote one of
> your examples:
> 
> ---
> bool constructMyStructScalar(ref Node node, out MyStruct result, out
> string customError)
> {
>      auto parts = node.as!string().split(":");
> 
>      try
>      {
>          result = MyStruct(to!int(parts[0]), to!int(parts[1]),
> to!int(parts[2]));
>          return true;
>      }
>      catch(Exception e)
>      {
>          return false;
>      }
> }
> ---
> 
> If the value is invalid, you just return false and let the library take
> care of the rest.  If you want to give detailed info about the error,
> assign to customError.  The code calling this function would throw an
> exception that contains the standard line and column info, plus your
> custom message.

Thanks for your input. Your example doesn't seem to be significantly 
simpler, but a good point is that the Mark structures don't need to 
be passed. I'm considering this style:

---
bool constructMyStructScalar(ref Node node)
{
     auto parts = node.as!string().split(":");

     try
     {
         return MyStruct(to!int(parts[0]), to!int(parts[1]), to!int(parts[2]));
     }
     catch(Exception e)
     {
         throw SomeExceptionType("message: " ~ e.msg); //wrapped by the caller
     }
}
---

This would avoid passing the Marks and force the user to specify an 
error message.


As for performance, I wouldn't expect D:YAML to be faster than a well 
written XML parser. YAML has a rather complicated spec due to its goal 
of human readability. A faster parser could be written if various less 
commonly used features were left out, e.g. if only a subset equivalent 
to JSON would be supported. 

Still, I'm interested in the results - both time taken and memory usage - 
maybe something could be found to further improve D:YAML performance.

If you have any more ideas on how to simplify D:YAML API, I'd like to 
see them. I'm only planning to freeze the API with a 1.0 release 
(which must wait for some Phobos changes), and would like to make it as
good as possible until then.