search

trevordevore / levure

Application development framework for LiveCode
MIT License
32 stars 14 forks source link

Modify levureAppGet to pull subkey values #120

Closed macMikey closed 5 years ago

macMikey commented 5 years ago

levureAppHasProperty checks to see if subkeys exist. Should levureAppGet do the same thing, or should we 

put levureAppGet("key") into keyArray
if leureAppHasProperty ("key","subkey") then put keyArray["subkey"] into goop
trevordevore commented 5 years ago

How about this?

https://github.com/trevordevore/levure/pull/122

macMikey commented 5 years ago

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")

trevordevore commented 5 years ago

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")
macMikey commented 5 years ago

I'd vote >. It sticks out more when reading.

trevordevore commented 5 years ago

👍

macMikey commented 5 years ago

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.

trevordevore commented 5 years ago

I don't like the idea of using , for the separator. It represents items which is not what we are representing here.

macMikey commented 5 years ago

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)

macMikey commented 5 years ago

So we're dumping the n-parameter model for the > model, right? I'm working through the logger issues.

trevordevore commented 5 years ago

Yes. The n-parameter model has never actually been released. It was only part of this PR earlier on.