Index into a struct to access a #Definition

[mikelnrd]

Is your feature request related to a problem? Please describe.

Hi. How can I index into a struct to access a #Foo (a cue definition) and not ("Foo" or "#Foo" regular fields).

// > cue version
// cue version 0.2.0 linux/amd64

// definitions is a struct here
// but it could equivalently be an imported package
// (at least I think the two are equivalent!)
definitions: {
    #Foo: {...}
    #Bar: {...}
    // many more definitions here...
}

// simplest example of what I was trying to do is as follows:

field: "Foo"

attempt1: definitions[field] //error! undefined field "Foo" (I don't want Foo but rather #Foo)

// ok, so let's try with "#Foo":
attempt2: definitions["#\(field)"] //error! undefined field "#Foo" (that makes sense, as "#Foo" could be a name of a field)

// So my question is, how can I index into the definitions struct to access a #Foo (a cue definition) and not ("Foo" or "#Foo" regular fields)

I also tried this and got the same "undefined field Foo" error:

#Definitions: {
    #Foo: {...}
    #Bar: {...}
    // many more definitions here...
}

name: "Foo"
#Test: #Definitions[name]
#Test: #Definitions["#\(name)"]

I like the new idea from the latest release notes of thinking of #-prefixed things as a separate namespace (for definitions).

I just can't work out how to do the indexing above! Is this currently possible? (and if not, please consider it a feature request)

[verdverm]

This GitHub repo has access to the pre-beta Discussions https://github.com/cuelang/cue/discussions

That will be a better place for questions of this nature, as is chat.

I'm not exactly sure what you are trying to do, could you clarify more? What do you want to do with the #Def after retrieving it?

Also make note, values and defs will be changing slightly in a release (the next?) @mpvl is working on this now and knows all about this. Not sure if docs are up anywhere, there are explanations about it and how things will work differently.

[mikelnrd]

I'm still learning cue (and of course cue is a still very much a moving target). I've read the recent release notes which explain the idea that you can think of definitions and values as two different namespaces (with definitions being prefixed with '#'). I guess based on that I was expecting to be able to lookup a definition as I can lookup a field, eg definitions["#Foo"] where the key used is a variable. I think being able to manipulate definitions as you can manipulate regular values is a very powerful idea. 

I'm afraid I can't remember the exact scenario where this need came up as it was a week or two ago. I've been working with kubernetes definitions (of which there are many!) and I think wanted to pluck out some of the definitions based on a list of strings. If I hit this again I'll report back...

---

Ah yes I've been eagerly awaiting Github Discussions but hadn't noticed the cue repo already has them! I don't think I can hit a button to make this thread a discussion unfortunately but I'll certainly post there in the future and join in on chat more...

[mikelnrd]

Just noticed this latest commit by @mpvl that looks related 53d18cc albeit on the go side of the code rather than in cue.

Also related is the idea of 'dynamic definitions' which I need to think more about and see if I'm using them or can get by without them. Just linking here for future reference (for myself and others)...

---

Search 'dynamic definitions' here:

#307 (comment)

https://github.com/cuelang/cue/releases/tag/v0.2.0

[mpvl]

One idea is that if people need indexable definitions, they could add an indirection, so in your case:

#Definitions: {
    #: Foo: {...}
    #: Bar: {...}
    // many more definitions here...
}

name: "Foo"
#Test: #Definitions.#[name]

But that won't work if the definitions are a given.

The question is what the use case is for dynamic definitions.

The only way around having full dynamic lookup for definitions is in the form of a language change, for instance allowing foo.#(name). Syntactically this could be done by allowing any expression after a .. We already plan to allow foo."str", foo.0, and even perhaps foo.(expr). The #(name) would be a CallExpr in this case.

The question is how much people really need this functionality.

[cueckoo]

This issue has been migrated to cue-lang/cue#421.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.