Skip to content
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

nesting proposal : allow full fledged toml to be nested inside inline tables #898

Closed
lizelive opened this issue May 4, 2022 · 5 comments

Comments

@lizelive
Copy link

lizelive commented May 4, 2022

creature.crow = {
    color = "black"
    [name]
        singular = "crow"
        plural = "crows"
        adjective = "crow"
    body_detail_plan = {
        standard_materials.remove_material = ['hair']
        [vertebrate_tissue_layers]
            skin = 'skin'
            fat = 'fat'
            muscle = 'muscle'
            bone = 'bone'
            cartilage = 'cartilage'
    }
}

variation.standard_quadruped_gaits = {
    args = ["walk", "trot" ]
    [cv_new_tag.gait.walk] = {
        [walk]
            full_speed = "!walk"
            no_build_up = true
            energy_use = 0
        [trot]
            full_speed = "!trot"
            energy_use = 0
            no_build_up = true
            layers_slow = true
            strength = true
            agility = true
            stealth_slows.percentage = 10
    }
}

pairs well with #897

@lizelive lizelive changed the title allow full fledged toml to be nested inside inline tables nesting proposal : allow full fledged toml to be nested inside inline tables May 4, 2022
@pradyunsg
Copy link
Member

Hi! Please see #781 which discusses the broader topic here.

@lizelive
Copy link
Author

lizelive commented May 6, 2022

#781 decided to go with "JSON-like"

#516 is an active discussion on how to do that by allowing newlines and trailing commas in inline tables

json is very nested. a value in json is also a valid json document. I like this cleanliness. it makes it easier to read + write json files.

This proposal makes toml tested like json by allowing values to be toml documents in their own right instead of restricting inline tables to very strict subset.

This means that toml documents should support

#516 as written requires a lot more characters and is harder to read

also is incontinent with the rest of toml on whether or not it requires a , after assignment because value is nested

you can compare

creature.crow = {
    color = "black"
    [name]
        singular = "crow"
        plural = "crows"
        adjective = "crow"
    body_detail_plan = {
        standard_materials.remove_material = ['hair']
        [vertebrate_tissue_layers]
            skin = 'skin'
            fat = 'fat'
            muscle = 'muscle'
            bone = 'bone'
            cartilage = 'cartilage'
    }
}
creature.crow = {
    color = "black",
    name = {
        singular = "crow",
        plural = "crows",
        adjective = "crow",
    },
    body_detail_plan = {
        standard_materials = { remove_material = ['hair'] },
        vertebrate_tissue_layers = {
            skin = 'skin', 
            fat = 'fat',
            muscle = 'muscle',
            bone = 'bone',
            cartilage = 'cartilage',
        }
    }
}
  1. easier to read
  2. harder to make parse error (forgetting a , is an error)
  3. it takes 235 chars vs 250 to represent the same thing cleaner
  4. doesn't restrict user to bootleg yaml with = instead of : for some reason
  5. 6% more efficient

@eksortso
Copy link
Contributor

eksortso commented May 6, 2022

I think that allowing table and array-of-tables headers inside inline tables violates a basic principle of TOML. The names wrapped in the [] and [[]] section headers should be absolute paths, never relative.

The table sections are an important part of TOML. We're not trying to re-create JSON. Those headers are supposed to stand out.

@marzer
Copy link
Contributor

marzer commented May 6, 2022

@lizelive, @eksortso writes

We're not trying to re-create JSON

I think maybe that's something you should reflect on. You have some good ideas, but all of them vaguely have fallen in the "TOML is not JSON but I really want it to be" camp. Might be worth asking if TOML is actually right for your use case, and not just switching to JSON?

@eksortso
Copy link
Contributor

eksortso commented May 8, 2022

The one thing that I do like here is separating key/value pairs with newlines, with no need for commas. I had a much stricter proposal, #525, that didn't gain much traction. I may make another case for this (one that isn't so restrictive, that's for sure) but not before we resolve #516.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants