hrszpuk / odin-ini Goto Github PK

• has_key
• has_section

The Options.Rules.* need to apply to parsing and the reaction:

• AllowEmptyValues -> if false then error
• AllowEmptySections -> if false then error
• AllowNestedSections -> if false then treat nested sections as 'standard' sections. The nested symbol becomes part of the identifier.
• AllowSpacesInKeys -> if false then error
• AllowSpacesInValues -> if false then error
• AllowDuplicateKeys -> if true then use the last duplicate, if false then error
• AllowDuplicateSections -> if true then use the last duplicate, if false then error
• IgnoreCaseSensitivity -> if true then case fold to lowercase
• IgnoreDelimiterPadding -> if true then any whitespace around the delimiter is ignored, otherwise, if false, it becomes a part of the key/value.
• IgnoreSectionNamePadding -> if true then any whitespace around the section name is ignored, otherwise, if false, it becomes a part of the section name.
• IgnoreValueQuotes -> if true then the quotes around values, "value", are ignored (value), otherwise, if false, the quotes become part of the value ("value" will be "value" not value.)

• write_to_file
• write_to_handle
• write_to_json

The issue is what clear from the title. Just need to free memory before delete_key is called.

The layout of the config struct allows for nested sections but write_to_string does not support nesting and instead treats nested sections as top-level sections.

Changing any of the Options.Symbols.* should parse/serialise the symbol stored.

• read_from_handle
• read_from_json

Surprising lack of code commands and general documentation for the parser.

This is currently inconsistent.

There are a number of methods that can fail, or cause issue, but nothing is raised.

A prime example is #17.

I'm going to leave a list of functions here that will probably cause issues:

• add_section overrides old value without freeing #17
• set_key same as above #17
• set_section same as above #17
• get_key will return cause issues when a key does not exist (ok-optional syntax would be good here)
• get_section will return nil when a key does not exist
• All functions that take ^Config need to check it is not nil

There already exists some debug printing but it is very minimal.

There is a log library in core that could be used to improve the messages.

Checklist:

• Lexer
• Parser
• Config functions
• Write functions
• Read functions

May want to change the structure of some of the code to make logging easier (like adding a new_token function so the log can easily show when a new token is created).

Fulling INI parsing with a standard syntax (then adjust for options later)

The README needs some improvements.

1. A large logo isn't needed for such a small library and I think it would be better to just use text.
2. Information about the features provided why they are provided
3. Provide an example of the library's functions: parsing, modifying, serialising should be shown.
4. Mentions speed in the description, do we have benchmarks?

// Section name appends to a "prefix" which is made up of the previous structs.
            if prefix {
                section_head := fmt.aprintf("%s%v%s", c.value, Options.Symbols.NestedSection, value.value)
                strings.write_string(&sections, section_head)
                new_value := fmt.aprintf("%s%v%s", c.value, Options.Symbols.NestedSection, value.value)
                delete(value.value)

                // TODO(hrs) directly modifying the values means post-serialisation values will be different... If you serialise twice you'll get double the nesting.
                // Perhaps "prefix" could be a string of previous nesting? Override it for each new section/nested section.

                value.value = new_value
                delete(section_head)
            } else {
                strings.write_string(&sections, value.value)
            }

Directly modifying the section's value is a bad idea. This means serialising more than once will lead to repeated identifier names.

Lexer supports lexing comments and gives them to the parser. However, the parser ignores them and they are not stored within the config struct or generated during serialisation.

Adding comments to the config would be nice.

One of the issues we might face is how to store comment placement within the config so the serialised output is correct.

Comments can be in the following places:

; empty line comment
[section] ; after section comment
key = value ; after key/value comment

All comments after a section could be stored within that Section/Config and all comments after key/values could be stored within the key/value itself.

An example:
Assuming the following ini config:

; config.ini

key = value ; this is a key value

[section] ; this is a section

; here are my keys
key = value 

The config layout would look like this diagram.

Each comment would be stored in a list in order of their position.
During generation, the list of comments, and the position of the comment within the list, is used to generate a similar INI file:

; config.ini
key = value ; this is a key value

[section] ; this is a section
; here are my keys
key = value 

(notice some whitespace is not accounted for, this is purposefully depicted.)

• remove (done but needs fixing, see #21)
• remove_key
• remove_section
• pop_section
• pop_key
• clear

add_section, set_key, and set_section do not check whether a key already exists. This is an issue as they immediately override the value in place which means it will not be deleted via destroy_config. These methods should delete the data stored at a key before assigning data to it.

In addition to this, some kind of "safe" versions of these functions (of perhaps a parameter) could be implemented that return an error instead of immediately overriding the data in place.

• #24
• #25
• #26

Complete forgot to implement this. The nested section symbol isn't even tokenised 🤦.

• keys gets all keys in a config
• sections get all sections in a config
• values get all values in a config
• iter run a procedure across the entire config (giving data to the handle)