Map.take is not a good name

Yep, that’s why in my first reply I was returning entries as {key, value} tuples, or nil if missing. But then of course Map.values/2 is the wrong name. Maybe Map.entries/2?

In the end, I feel this is something that one can build on top of the provided core functions and adapt it to the specific need. Not a good candidate for a new core function in my opinion.

1 Like

I would expect it to return nil just as Map.get(map, key) does when the key does not exist in the map. It’s up to the caller to reject nils or not. values!/2 could raise as fetch!/2 does.

True, but Map.get/3 allows to specify a default, which in the case of Map.values/2 (or Map.values/3 with the optional default) would have to be a single default for all the missing values, or a function to compute the default. At that point, the function starts to be substantially different from values/1 to deserve its own name.

I think we’re going way too far off on a tangent here. I don’t care what color the bikeshed is painted :smirk: I made a throw-a-way comment about values/2 but since it’s a one-liner, I don’t plan to make a proposal to core because I don’t care enough to argue the case.

If you need to supply a default, then yeah, you’re talking about something different, and IMHO it’s probably best written explicitly in your application’s domain logic.

2 Likes

Hello all,

I just wanted to say that seeing such encouragement to propose things (even in the core) without shaming noobs (which I personally am regarding Elixir) is very, well, encouraging!

I had some idea too… After some practice and study, I’ll definitely try to jump on the bandwagon.

1 Like

I think ‘slice’ is better :slight_smile:

I don’t think it is productive to weigh in this way 3 years later. All other uses of slice in Elixir (and a lot of other languages) use slice with index based operations.

1 Like