JDevlieghere added a comment.

In D85705#2237506 <https://reviews.llvm.org/D85705#2237506>, @clayborg wrote:

> In D85705#2237397 <https://reviews.llvm.org/D85705#2237397>, @JDevlieghere 
> wrote:
>
>> A large part of this patch is concerned with parsing which worries me from a 
>> maintenance perspective. Did you consider using Yaml I/O 
>> <https://llvm.org/docs/YamlIO.html>? While I'm not a particularly big fan of 
>> the format, the benefits of being able to (de)serialize any class by 
>> implementing the appropriate traits are quite significant. We already have 
>> traits implemented for a bunch of utility classes, such as `ArchSpec` and 
>> `FileSpec` which we could reuse for this. I know changing the format would 
>> be invasive, but I think it might be worth it in the long term.
>
> So the nice thing about using StructuredData is it can be in any format: 
> JSON, XML, Apple property list, YAML etc. It seems like the functions that 
> were added to ArchSpec and FileSpec for the YAML I/O could be converted to 
> use StructuredData and then any of the formats would work.

If we invest in creating a library like Yaml IO for StructuredData, which 
allows you to declaratively specify how a class gets (de)serialized, then I'm 
all for using it here and for the reproducers. I think that would be really, 
really valuable. Given the way that structured data works and how similar it is 
to how these formats look, I'm also fairly confident it can be done. Still it 
would be a significant amount of work. But barring that I don't see a benefit 
from switching from YAML I/O to StructuredData, at least not for the 
reproducers and not really for this either. Unless we need to be able to 
support all these formats? Like I said, I don't really care about YAML. What I 
do care about is that I don't want to be in the business of writing a parser 
for every data structure I need to serialize. That's really where Yaml I/O 
shines, even though it has other drawbacks, like the traits themselves being 
verbose and the parser being far from fast.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85705/new/

https://reviews.llvm.org/D85705

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to