Requesting feedback from devs on my configuration format

[Justis]

Hey again,

About six years ago, I developed a configuration format for my own use in all of my projects, both personal and professional.

A few days ago, I redeveloped it from scratch and have now published it as a public repository: https://github.com/justisr/HMFF

The format is similar to YAML but with some important differences:
- No need for string encapsulation
- No need for character escaping
- All path keys can have values
- No use of periods in path specification
- No complex data structures within the configuration
- Flexible interpretation, won’t error at formatting mistakes (no snakeyml)
- Actual comment support (add/edit comments dynamically)
- I’m pretty sure it’s faster as well, but I haven’t bothered testing that

One thing I want some opinions on though, is actually related to the comments.

Currently, any comment which appears above a key will be attributed to that key.
The root (file) comments are thus attributed to the footer, i.e comments that appear after all of the structure’s keys.

However, many developers want to add headers to their files, rather than footers, and a developer may not know which key to write the header to, because they might not know which key appears first in the file.

On the other hand, specifically writing in support for a file header conflicts with how comments are currently attributed, since the header will appear above the first key. It will either end up attributed to the comments of the first key on reload, or I’ll have to modify the format’s concept so that whitespace appearing between the header and the first key’s comments acts as a real and meaningful indicator; something which isn’t the case for whitespace appearing anywhere else in the file. I hate exceptions.

Nonetheless, I’m currently of the opinion that I should bite the bullet and make that specific whitespace a real and meaningful indictor anyway, because a header’s contents don’t necessarily belong to the first key that appears within the file, so it’d be a much greater violation of the format's concept to attribute them in that way.

Just wondering if anyone has any thoughts.

 

[Ally]

- No complex data structures within the configuration

I assume therefore this is limited to things you can serialise to a string? (Pretty much everything)
Any multiline support for values?[DOUBLEPOST=1632881069][/DOUBLEPOST]

Nonetheless, I’m currently of the opinion that I should bite the bullet and make that specific whitespace a real and meaningful indictor anyway, because a header’s contents don’t necessarily belong to the first key that appears within the file, so it’d be a much greater violation of the format's concept to attribute them in that way.

Whitespace as a delimiter sucks.
Perhaps use a proper delimiter to denote sections of the file. Header, config, footer. A hyphen on a newline, for example, or as many hyphens as you'd want. It would be pretty easy to find the config section while ignoring the header and the footer. Moreover, you could include multiple config sections. (The easiest way is to read every section as a config section and just verify if there are any keys in that section. Ideally the header/footer would have none)

 

[Justis]

I assume therefore this is limited to things you can serialise to a string? (Pretty much everything)
Any multiline support for values?

Since each section is a map, your means for creating multi-line values would be to create another section.
You could, for instance, create a set of numbered child sections within a section and use their values for storing their data.
Listing the child sections and adding their values to a list would then result in a list of values under the parent section.

Maps are a simple yet incredibly versatile data structure, and I appreciate php's philosophy of using them as the backbone for even arrays.

I see any additional syntax for multi-line values as a detriment more than anything, for breaking what would have otherwise been a clean and consistent data structure.

Whitespace as a delimiter sucks.
Perhaps use a proper delimiter to denote sections of the file. Header, config, footer. A hyphen on a newline, for example, or as many hyphens as you'd want. It would be pretty easy to find the config section while ignoring the header and the footer. Moreover, you could include multiple config sections. (The easiest way is to read every section as a config section and just verify if there are any keys in that section. Ideally the header/footer would have none)

Too messy and I definitely don’t want multiple root sections. The root effectively has no key, since it represents the whole file. All non-indented sections within the file are the root’s (file’s) child sections. Allowing for multiple roots when the whole file is the root, would break that design. It would also be impossible to refer to a specific root without giving it a key within the file, and at that point, you’ve simply created a section but with unnecessarily differing syntax.