proposal-collection-normalization
proposal-collection-normalization copied to clipboard
Understanding the underlying problem better
I've reviewed this proposal. I understand the usecase, but I don't have a good grasp of what the underlying problem is, precisely, that requires this specific design rather than something else. For example, the map or set could be transformed in one go into another kind of map or set. This would require that all of its members are expected toe be of the same type, but the same assumption seems to be present in the proposal?
So, I would love to see an elaborated motivation section.
For example, the map or set could be transformed in one go into another kind of map or set
I'm not sure I understand this suggestion.
This would require that all of its members are expected to be of the same type, but the same assumption seems to be present in the proposal?
I'm not sure there is any force of types in the proposal, for example a HTTP header Map could transform some values into arrays if there are multiple header lines but keep strings in the case that only 1 header line of a given name exists (this would for example closely match how HTTP request/response headers work in Node).
So, I would love to see an elaborated motivation section.
Would listing existing data structures in various ecosystems that would be more easily created or have a standardized approach to their solutions be sufficient?
I've added a few things to the README that may help