With the original implementation in my PR, arrays were not supported, and the other types in TOML were not specifically tested.
Feel free to make changes to the unit test, if you find this too bloated.
TOML types: string, integer, float, boolean, offset date-time, local date-time, local date, local time, array, table
string, integer, float, boolean
All working before
array
I have implemented arrays by deserializing their contents well, and joining with ;.
This is how environment variables work, and properties seems to have common conventions.
I am unsure how Avaje Config supports lists, currently. Is it by repeating the same key multiple times, with each value? If that's the case I could implement it this way instead.
local date, local time, local date-time, offset date-time
Maps to JVM - LocalDate, LocalTime, LocalDateTime, and OffsetDateTime.
They have direct implementation in TOML, and the toString() is called from the JVM class to give us a string in the map.
This leaves us with an ISO-8601 value.
This value can be immediately passed in to the static parse methods, e.g. LocalTime#parse, if someone wants to use these TOML features easily.
var time = LocalTime.parse(Config.get("some_localtime"))
table
Intermediary tables are not supported, but the normal tables are "un-nested", i.e., dotted, and this was working before.
I don't know yet if it would be worth implementing this, because with the API that avaje-config exposes, it would be hard to actually use them?
For basic ones like this, the parser can be further expanded to "un-nest" them, i.e. make new dotted keys for their contents
But what about intermediary tables, in arrays? Users can't read them with our API right now, so they shouldn't use them
If using them, the value will read org.tomlj.MutableTomlTable@2u0rjqai, etc.
With the original implementation in my PR, arrays were not supported, and the other types in TOML were not specifically tested. Feel free to make changes to the unit test, if you find this too bloated.
TOML types: string, integer, float, boolean, offset date-time, local date-time, local date, local time, array, table
string, integer, float, boolean
All working before
array
I have implemented arrays by deserializing their contents well, and joining with
;
. This is how environment variables work, and properties seems to have common conventions.I am unsure how Avaje Config supports lists, currently. Is it by repeating the same key multiple times, with each value? If that's the case I could implement it this way instead.
local date, local time, local date-time, offset date-time
Maps to JVM - LocalDate, LocalTime, LocalDateTime, and OffsetDateTime. They have direct implementation in TOML, and the toString() is called from the JVM class to give us a string in the map. This leaves us with an ISO-8601 value.
This value can be immediately passed in to the static
parse
methods, e.g.LocalTime#parse
, if someone wants to use these TOML features easily.var time = LocalTime.parse(Config.get("some_localtime"))
table
Intermediary tables are not supported, but the normal tables are "un-nested", i.e., dotted, and this was working before.
Intermediary table:
some_key = { one: 1.0, two: 5.0 }
I don't know yet if it would be worth implementing this, because with the API that
avaje-config
exposes, it would be hard to actually use them?For basic ones like this, the parser can be further expanded to "un-nest" them, i.e. make new dotted keys for their contents
But what about intermediary tables, in arrays? Users can't read them with our API right now, so they shouldn't use them If using them, the value will read
org.tomlj.MutableTomlTable@2u0rjqai
, etc.