-
Notifications
You must be signed in to change notification settings - Fork 87
Add extension methods for converting between maps and records #289
Conversation
I'm not particularly fond of treating maps as sets of pairs. On the other hand, if records had existed when we added Should users use one or the other? If this is just to save typing, I don't think it's particularly convincing. for (var (:key, :value) in map.entries) { ... } and then doing for (var (key, value) in map.pairs) { ... } isn't much of a saving. It's just an almost identical way to write almost the same thing, so users might just mix and confuse two. (If I get to make You should almost never have to create a Which means that the same should apply for creating pairs in order to create a map or add to a map. So, not convinced this PR is solving a problem that isn't already either solved adequately by (One could also just have: extension EntryPair<K, V> on MapEntry<K, V> {
(K, V) asPair() => (key, value);
}
extension PairEntry<K, V> on (K, V) {
MapEntry<K, V> asMapEntry() => MapEntry($1, $2);
}
extension EntryPairs<K, V> on Iterable<MapEntry<K, V>> {
Iterable<(K, V)> asPairs() => this.map((entry) => entry.asPair());
}
extension PairEntries<K, V> on Iterable<(K, V)> {
Iterable<MapEntry<K, V>> asMapEntries() => this.map((pair) => pair.asMapEntry());
} and do the conversion to/from pairs as needed.) |
I've been converting a considerable amount of code to Dart 3 style, and I find this extremely useful (specifically for (var (args, callback) in overloads.pairs) than either |
I'm not entirely convinced, but I think I'd be more likely to accept just: extension ... on MapEntry<K,V> {
(K, V) asPair() => (key, value);
}
extension ... on List<MapEntry<K, V>> {
Iterable<(K, V)> asPairs() => map((e) => e.asPair());
}
// and just maybe:
extension ... on Map<K, V> {
Iterable<(K, V)> get keyValuePairs => entries.asPairs();
} I can see how that would make it easier to consume map key/value pairs as themselves, rather than seeing them only as actual map entries. I'm not sold on using those pairs to build new maps again. There should be better ways to do that. @natebosch WDYT? |
I don't think we should need I would use the name
+1 - especially at the top level I don't think it's worth a method for creating a fresh map from pairs. I could go either way with
That's also the only API I would imagine should get much use. I don't think it's worth adding the others for consistency. |
I think if the expectation is that I'd like to gently push towards keeping the name |
They're not. If we didn't have them today, I wouldn't add them. The And if records had existed then, we wouldn't have the I can see the conciseness of But if I just saw (Mathematically, |
I think |
I mean, List has With a map, I think it's pretty obvious that the "pairs" in a map would be the key-value pairs. And the natural way to represent a pair in Dart 3 is a two-positional-field record. I think the name works pretty well. |
A A (I've not been particularly successful in discouraging that view, so maybe |
I'm not sure why you've tried to discourage the view of maps as "pairs of keys and values", but I think it's worth pointing out that the very first words in the Map documentation are "A collection of key/value pairs" so I think that battle may already be lost. |
Fair. I'm really discouraging using a linked hash map instead of, what can to day be written as, a So a map is a set of pairings, but if someone say "the pairs of a map", the key/value pairs is not necessarily my first thought, that very much depend on the map. That may just be because I'm overthinking it. I haven't found a better name than |
No description provided.