Please note that "maps.Collect" is slow. https://github.com/golang/go/issues/68261 It is best to write your own custom Collect function.
On Monday, December 30, 2024 at 5:50:47 AM UTC+8 Mike Schinkel wrote: > > On Dec 29, 2024, at 1:28 AM, Axel Wagner <axel.wa...@googlemail.com> > wrote: > > > > At the end of the day, it's purely a question of what you think would be > more frequently used. That should get the better name. `Values` (as is) > composes naturally with `slices.Collect` and so you get both in one > function and it seems a good choice for the default option. > > In my projects I use the sequence versions less frequently so having > maps.Keys() and maps.Values() return an actual slice would be preferable. > As is, I am forced to use the far less better name of > `maps.Collect(maps.Keys())` instead of just `maps.Keys()`. > > Why don't I use the sequence versions more frequently? Because I try not > to create huge in-memory maps and instead prefer to move logic that > manipulates large amounts of data into a proper database. > > But when I do it would use large maps it would make sense to call that out > with maps.KeysSeq() et. al. > > > I don't see a good argument for the lack of a suffix "naturally" > implying returning a slice. I don't think `ValuesSlice` would be less > natural than `ValuesSeq`. > > > > In any case, the existence of this discussion is a historical accident. > We added `x/exp/maps.Values` before iterators existed, as an experiment, so > had to use slices. We *intentionally* waited with adding `maps.Values` > until *after* iterators got added, to be able to give it the better name. > If we would have never had `x/exp/maps.Values` or if we had added `range` > over func before generics (and AFAIK it has been proposed before generics), > we would have only ever had a `maps.Values` that returned iterators. No one > would have even noticed. > > Ironically you alluded to the good argument you did not see, in your third > paragraph. > > The good argument is precedence and consistency. I do agree that had it > not been for the historical "accident" things would be different, but > history is not something you can merely hand-wave away; it exists and has > significant influence even when there are those who would prefer to ignore > it. > > Had that history never occurred I would agree that a lack of a suffix > would not naturally imply a slice. But that history did occur, and naming > is not good when it ignores the context that occurred before it. > > The decision to ignore precedence and consistency is taking steps toward > the "fractal of bad design" that is PHP and its horrendous inconsistency in > standard library function naming and parameter usage that people have > complained about for decades. > > Anyway, I am not sure why you felt the need to add your voice to defend it > because, as I wrote, "That ship has sailed." > > -Mike > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/fa77804f-e03c-4b13-b499-96ce7cf08f61n%40googlegroups.com.
