proposal-collection-normalization icon indicating copy to clipboard operation
proposal-collection-normalization copied to clipboard

Understanding the underlying problem better

Open codehag opened this issue 4 years ago • 2 comments

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.

codehag avatar Mar 04 '21 12:03 codehag

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?

bmeck avatar Mar 09 '21 19:03 bmeck

I've added a few things to the README that may help

bmeck avatar Mar 09 '21 20:03 bmeck