Quoted keys shouldn't need the quotes

[pie-flavor]

I have beef with the policy on quoted key loading. It doesn't make sense to require that the query have the same quotes. The point of quoted keys are that the quotes only exist in the file, theyr'e not part of the key name. There should be at least a boolean parameter whether or not to load it this way.

[mwanji]

I would argue that the quotes are part of the key. What in the spec makes you think otherwise?

[pie-flavor]

@mwanji In no other configuration library have I ever seen this functionality. The name is not the quotes, the name is what's in the quotes.
Again, even if you differ on what you believe a configuration library should load like, I am asking for at least a boolean parameter when loading for whether or not to involve the quotes.

[bruno-medeiros]

I agree, the quotes are not meant to be part of the quoted keys, they are just a syntactic delimiter. This can be seen in the spec: https://github.com/toml-lang/toml#keyvalue-pair where it says: "Quoted keys follow the exact same rules as either basic strings or literal strings and allow you to use a much broader set of key names". This means the quotes are not part of the key name, just as they are not part of the string value.

This also apples to table key names, and again can be seen from this example in the spec ( https://github.com/toml-lang/toml#table ) :

Naming rules for each dot separated part are the same as for keys (see definition of Key/Value Pairs).

[dog."tater.man"]
type = "pug"

In JSON land, that would give you the following structure:

{ "dog": { "tater.man": { "type": "pug" } } }

If quotes were part of the key name, then the equivalent JSON for the TOML above would instead be:

{ "dog": { "\"tater.man\"": { "type": "pug" } } }

but it's not.

[mwanji]

OK, I'm convinced and will change this behaviour soon.

[mwanji]

I have an issue that you might be able to help me solve. Quoted keys allow the use of dots and square brackets. This conflicts with the deep navigation feature, eg. toml.getString("dog.tater.man.type") == "pug".

Currently, this expects a table called tater containing another table called man. I guess I could use some heuristics to discover that there is a table called tater.man, but this seems messy, error-prone and confusing.

The use of square brackets (outside of quotes) indicates array navigation, but now any random use of square brackets would have to be understood. What if someone calls a table "dog[2]", then calls toml.getTable("dog[2]")?

[pie-flavor]

@mwanji In the Configurate library, which I use frequently, instead of calling node.getNode("foo.bar.baz"), you call node.getNode("foo", "bar", "baz"). That's one solution. Another solution is to have an overloaded method which additionally takes a char or maybe string to be used as the separator (i.e. toml.getString("dog:tater.man:type", ':').

As for the random square brackets, I'm curious as to why you've got the current format. I've never seen a configuration library do that. The string is the key, yes? Why is extra information that isn't the key also in the string? I'd personally change that to be a separate method. Or just don't include it - people could easily do an inline call to getTables("listKey").get(0).get("otherKey").

Edit: Alternatively, to avoid breaking existing code, you could do another method overload here: toml.getString("dog%0.food[4]", '.', '%')

[bruno-medeiros]

Yeah, I essentially agree with @pie-flavor.

You'll need an API like node.getNode("foo", "bar", "baz"). I imagine the deep navigation feature is probably not used in practice though? It wouldn't be the end of the world to drop it, or move to utility class. The more important API will be the regular, one-level deep access.

You're going to have some issues with backwards compatibility too...

[mwanji]

Thanks for the feedback, @pie-flavor and @bruno-medeiros . I'll change the existing method to a varargs.

I'm not really worrying about backwards compatibility until TOML goes 1.0, which is when this library will, too. However, someone using the deep navigation feature will start getting erroneous results after upgrading. Is there anything I could do beyond documentation? Print out a warning if a key with a dot in it doesn't point to anything?

[pie-flavor]

Usually my solution to this is to ignore it - it's on them for not reading the updated documentation. If only there was a way to put a message in the NullPointerException.

[bruno-medeiros]

Definitely you shouldn't print a warning: some programs need absolute control of what goes into stdout and stderr, and toml4j shouldn't interefere with that.

[pie-flavor]

@mwanji Once it has a varargs in it, all existing calls to the method will break, since the signature has changed. They can look up why their code is breaking, and notice the difference then. But I agree with @bruno-medeiros.

[pie-flavor]

Any sort of status on this?

[mwanji]

@pie-flavor Sorry this is taking so long. I have done some work on it, but repeatedly ran into issues. Latest was that the varargs approach conflicted with the existing way to provide a default value, ie. getString("keyName", "defaultValue"). I still haven't found a way to fix that for Java 6, but it prompted me to get started on the Java 8 version of the library that I'd been wanting to do for a while.

With Java 8's Optional, I can eliminate the default value overload, and use it for navigation instead. The API looks like this: Optional<String> optString(String).

Plus, Java 8 will provide much better support for the more sophisticated date/time system that has been added to TOML.

I'll publish this work in a branch as soon as I can, and let you know.

[pie-flavor]

Status update?

[pie-flavor]

happy belated third birthday to this super basic issue

[gamma-delta]

wow, pie flavor in the wild

anyways yeah im switching to a different toml library this is ridiculous