Add support for using nested lists and maps #39
Conversation
| @@ -418,16 +418,21 @@ func slice(start interface{}, end interface{}, increment interface{}) ([]int, er | |||
|
|
|||
| // Return the keys in the given map. This method always returns the keys in sorted order to provide a stable iteration | |||
| // order. | |||
| func keys(m map[string]string) []string { | |||
| func keys(value interface{}) ([]string, error) { | |||
There was a problem hiding this comment.
Today's example of Go being a shitty language: without generics, in order to support map[x]y for arbitrary x and y, I had to remove all types from the code and use reflection. That makes the code harder to read and more brittle. We've known how to do generics for several decades; there is no excuse for this.
| case reflect.Map: | ||
| values := map[interface{}]interface{}{} | ||
| for _, key := range valueType.MapKeys() { | ||
| renderedKey, err := renderVariable(key.Interface(), variables, options) |
There was a problem hiding this comment.
Example 2 of Go being a shitty language. Here, type casting is required, because the incoming type genuinely could be anything, but even once I know the type is a map, I still have no way to express map[x]y for arbitrary x and y, so I'm used to use a ton more reflection just to loop over the keys and values. Brittle code that's harder to read = no fun.
|
Merging now. Feedback welcome! |
This PR updates boilerplate so that variables with type
listormapcan support nested lists and nested maps. It’s rare that we need such complicated data structures, but occasionally it’s useful, and it wasn’t a hard change to support it.