Closed ckampfe closed 6 years ago
Thanks for your contribution. I am thinking about it in terms of symmetry or lack thereof - we can easily convert UUIDs to strings when writing to the sheet, but we get strings out when we read them back. Is that the behaviour we want, or can we find another approach that preserves the symmetry at the same time?
You bring up a good point. It's tough because there is information loss.
Parsing a String->UUID
presupposes that the programmer (or library) knows that the data they are reading from a cell should be a UUID. Is it a good default to say that when reading, we will check to see if things look like a UUID, and if they do, construct a java.util.UUID
? This argument could be made for all sorts of types, as well. Strings that look like vector literals, things that look like character literals, etc.
This is kind of difficult to say in the general case. Other than Excel's built-in datatypes, are there instances in this library of converting from String->T
? Do we want to be choosing types for people? Is java.util.UUID
the UUID that everyone likes? etc.
You are pointing out a good number of reasons that it would complicate the usage scenarios. I like the library to be simple and easy to learn and use, so I am closing it for now. Thanks for taking the time working through the details of this.
adds ability to set a cell as the string representation of a
java.util.UUID
Thank you!