Closed macMikey closed 5 years ago
How about this?
Me likey, but it literally just occurred to me as I was reading this:
the quoted parameter list or array building is a little awkward/long.
levureAppGet("build profiles","all profiles","copy files","all platforms","filename")
What about using colons as a substitute for dot notation since colons in a YAML file are reserved?
levureAppGet("build profiles:all profiles:copy files:all platforms:filename")
I agree about the parameter list approach being too lengthy. :
is allowed, however, as long as you put the key name in quotes. Example:
"annotator: active tool": line
Levure currently uses the >
character in helper.yml files to point to a nested key when registering components. For example, SQL Yoga registers a key for storing properties in the configuration
subway of the sql yoga
key. This is the syntax:
register components:
- key: sql yoga>configuration
I went back and forth on whether to use :
, .
or >
. I settled on >
because it seemed the least likely to be used in a key name and to me the symbol implies nesting.
For levureAppHasProperty/levureAppGet
I could go either way. Using >
the syntax would look like this:
levureAppGet("build profiles>all profiles>copy files>all platforms>filename")
I'd vote >
. It sticks out more when reading.
👍
After sleeping on it, maybe ,
would be better still because it isn't another new symbol for someone to have to remember to use as a separator.
I don't like the idea of using ,
for the separator. It represents items
which is not what we are representing here.
I'm ok with >
. Comma would just mean one less thing to have to remember. I don't use commas for much of anything (The data we're pulling is always from a DB so it's tsv format)
So we're dumping the n-parameter model for the >
model, right? I'm working through the logger issues.
Yes. The n-parameter model has never actually been released. It was only part of this PR earlier on.
levureAppHasProperty
checks to see if subkeys exist. ShouldlevureAppGet
do the same thing, or should we