Adds the list of choices to the choice type

[jneug]

This allows access from other packages / templates to the list of choices available for this type.

[jneug]

As dicussed in #36.

[tingerrr]

Looks good to me.

Although I wonder if this should be available as a field on all base-types with a value of none or (), to keep the internal structure of base-type consistent, what do you think @JamesxX?

[jamesrswift]

On the one side, consistency would be nice, on the other, descriptive fields (especially when the shape of the data might change between schemas) might be the way to go

[jneug]

I'm not sure how this is supposed to work. A "choices" key wouldn't make much sense for other types than #choice. Or what do you mean by keeping it consistent? Types like #dictionary, #array and #either already expose additional keys that other types don't.

I can think of two kinds of types: "basic types" that check the type of the provided value against a list of allowed types and "complex types" that add some logic (assertions, pre-/post-transforms).

For these "complex types" unique keys might help identify them more reliably than the name. If a choices field exists, I'm dealing with some kind of choice type and not an array, while descendants-schema suggests the reverse.

[jamesrswift]

Good points and well made. When I get home tonight I'll go through each of the schema generators and see what needs changing

[jamesrswift]

In meantime, no reason why this shouldn't be merged. I'll keep open because there's some nice discussion on field names which will be important still

[jamesrswift]

One thing I'd like to change now that choices are stored in a field is for the assertion to read that field rather than keep it's own copy. It's a design I've tried to implement in the other generators so that (in this example) choices can still be changed after schema generation