Should a MultiInfo be recovered when serializing and parsing?
See original GitHub issueCurrently a MultiInfo
gets serialized in such a way that it is impossible to recover:
val info = MultiInfo(Seq(MultiInfo(Seq(FileInfo("a"))), FileInfo("b"), FileInfo("c")))
serializes to @[a b c]
which is then parsed as FileInfo("a b c")
.
Is this the expected behavior?
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Data Serialization - The Hitchhiker's Guide to Python
Data serialization is the process of converting structured data to a format that allows sharing or storage of the data in a form...
Read more >Parsing and Serializing - HAPI FHIR Documentation
A built in parser can be used to convert HAPI FHIR Java objects into a serialized form, ... HAPI FHIR does not have...
Read more >DOM Parsing and Serialization - W3C
Abstract. This specification defines various APIs for programmatic access to HTML and generic XML parsers by web applications for use in ...
Read more >Serializing Objects - JavaScript: The Definitive Guide ... - O'Reilly
Serializing Objects Object serialization is the process of converting an object's state to a string from which it can later be restored.
Read more >It is really tedious to write a bunch of data classes for parsing a ...
Some library with in-built magic that does these kind of stuff for me? json · kotlin · serialization · json-deserialization · Share.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes, but then it would be encoded as
file.scala 1:23\] @[other.scala 3:45
(note the escaped\]
). This isn’t the case in the current release but it will be fixed once my PR (https://github.com/freechipsproject/firrtl/pull/1690) is merged.Pedantically,
file.scala 1:23] @[other.scala 3:45
is a valid filename… (The number of sharp edges here is astronomical.)A perhaps naive approach would be to go to URIs/URLs to represent the file. This should make spaces actually work as identifiers here.
Java seems to let you go back and forth pretty easy: