-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adopt format agreed with Gemstone #52
Comments
I suppose this is not implemented yet because it will make every package in Pharo change on every commit when these changes got merged.
This way projects wanting to use the new format features can adopt them without disrupting projects on prior versions. I think in the case of Tonel we need to apply the Robustenss principle, and produce an output that is as deterministic as possible (via the TonelWriter) but be more lenient on the input (via the TonelReader). If we must produce a new format version I will say we need to consider #99 also. @tesonep @estebanlm @dalehenrich @eMaringolo @guillep what do you think? |
Most of the tonel readers will read any format and covert to the "correct" format internally (I think that is part of the tonel spec as well), but all tonel writers should write in the agreed upon format moving forward ... The longer that we wait to start writing the correct format, the bigger the problem will become ... So bite the bullet and fix the problem now and provide patches for all of the active versions of Pharo that are using tonel, so that the issues will be mitigated in short order ... I just noticed that Pharo (randomly?) writes mixed Strings and Symbols as values ...this was written 8 days ago and this was written 19 days ago ... hint look at the category field |
During ESUG (2017, so more than a year) we agreed a format for Tonel files that is slightly different from the one existing now.
We agreed:
This easies some parsing, etc.
The text was updated successfully, but these errors were encountered: