Closed Donavan closed 8 years ago
While it is reasonable to use the hash's keys as the implicit parameter list when adding a row of values without having any parameters already set, there are no implicit parameters to be had when adding a row using an array. For the sake of having consistent behavior for both adding rows by Array and adding them by Hash, I'd rather raise an exception in both cases rather than have one of them silently be helpful while the other can do nothing but explode.
Given that the only way to have an empty parameter list in the first place is to be intentionally manipulating the state of the Example object, it seems like a not unreasonable demand on the library's part that the user also intentionally set the parameters as well.
Regarding using non-string keys/values in the input arrays/hashes: sure, that's an easy enough thing to handle by 'stringifying' the input before processing it. However, it is possible to end up with a mix of strings and symbols as keys if the Example was parsed from source text (resulting in string keys for the initial rows) and then had rows added manually with hashes that used symbols for keys (any rows that were added manually would retain their symbol keys).
Again, for the sake of consistency, I'd prefer that all hash keys are the same kind of object and keeping them all strings will avoid changing existing behavior (in the non-exploding cases, that is).
TLDR: use whatever you like as input, but output will always be strings.
Merged.
This PR corrects a few minor issues I encountered when creating examples from scratch.
There's one non-bugfix change included here on the hash path. When handed a hash, use it's keys to populate the parameters array if that array is currently empty.