My case for null
#1040
Replies: 1 comment 1 reply
-
|
Part of your first use case is perplexing. If you "unset a default", then you have no default value. I believe what's implied is that there is, in fact, another layer of defaults below You could describe what you're doing as either:
In either case, it seems more like an artifact that emerges from your merge strategy. The simplest solution to me seems to be don't set it in " |
Beta Was this translation helpful? Give feedback.
-
|
you're wrong. there is no layer below default. If you want to be pedantic, fine: you can interpret my case as having When I say 'unset a default', I mean 'set a value defined in default.ts to some null-ish value'. This makes sense, because almost every programming language ever has a runtime representation of Say we are (hypothetically) designing a language for representing numeric values. Should we represent zero as You're right - using the current toml spec, not setting defaults at all is the only way of doing things. Your particular opinion about the obviousness of commented-out values is of little relevance, because I disagree, and others do too; the prevalence of those people does not matter, only that they exist. JSON does not support comments. |
Beta Was this translation helpful? Give feedback.
-
Motivating use-case 1
I come from the JavaScript ecosystem where we have a package called config.
I really like the pattern it implements. I end up setting up my projects like this:
Now,
default.tscontains a complete 'development' configuration, and is included in VCS.production.tscontains a partial configuration of overwrites that are applied conditional on theNODE_ENVenvironment variable, and is included in VCS.local.tscontains a partial configuration of overwrites that are always applied, but is not included in VCS.configlibrary will deep-merge the structures exported from these files in a consistent, predictable order.In practise, this is good for various reasons ...
default.tsacts as living documentation for the overwrite keys I can choose to add tolocal.ts,production.ts.default.tstoproduction.tswhen I make changes.local.tswithout affecting collaborators.local.tswithout exposing them via my VCS.Notably, though, for this pattern to work, I sometimes need to use
nullorundefinedvalues inproduction.tsin order to 'unset' values defined bydefault.ts.So when I came to trying to implement this pattern for a Python project using
.tomlfiles in place of.ts, I was fairly dismayed when I found out I can't havenullvalues in.tomlfiles!Motivating use-case 2
Say I have an 'optional' value which I load from a
.tomlfile.As long as the defined value for
foois not null-ish, it is obvious to any contributor to my project simply by looking in the config file that they can amend the value offooto have some effect on the project's behaviour.But if the defined value for
foois null-ish, I can eitherfoofrom the config fileBoth of these make it considerably less obvious to an arbitrary individual that
foois something they can amend the value of.Other remarks
nullandundefinedare simply 'sentinel' values roughly meaning 'the absence of a value'.If we want to get really silly, we could say TOML already supports
null-ish values ...Strategy 1: 'flags'
foo->nullbecausefoo_is_nullbaz->"qux"becausenot baz_is_nullStrategy 2: bring your own sentinel value
select an arbitrary value that is unlikely to ever show up in common use ...
and use it to represent
nullvaluesfoo->nullbecause its value is exactly the chosen sentinel valuebaz->"qux"because its value is not the chosen sentinel valuefin.
since
null-ish values are clearly 100% supported already (/s), what difference does adding anullkeyword make? it would save people the effort of runningopensslor duplicating all the keys in their files :0)I want to be arguing over
null/nil/none/undefined, not about whether TOML needsnull!Beta Was this translation helpful? Give feedback.
All reactions