> There are already a ton of ways to validate presence of keys at runtime -
Keyword.fetch!/2, Keyword.has_key?/2, Keyword.update!/3, Keyword.replace!/3
- all of which would spot a typo. What would this really add that would
provide meaningful feedback that those other functions don’t offer?
This
What would be really awesome is some kind of "rubric" for answering the
question "does this belong in the standard library". It could be as simple
as something like a set of criteria like "ubiquity", "utility", "new value
add", and some scores that it needs to exceed, e.g perhaps greater than a
There are already a ton of ways to validate presence of keys at runtime -
Keyword.fetch!/2, Keyword.has_key?/2, Keyword.update!/3, Keyword.replace!/3
- all of which would spot a typo. What would this really add that would
provide meaningful feedback that those other functions don’t offer?
I see
> But if we want to solve this problem as it was stated (how to give faster
feedback about typos) then the only thing I can see that would actually
solve the problem and let the developer know they have a typo is to use a
struct or to add some additional syntax for passing named arguments to
I don’t think the issue is with fetching the values, as we already have
Keyword.fetch!/2. The root cause of the issue is that there is connascence
of name between disparate places about the specific values in a dynamic,
unstructured data structure, and that there is no way currently to
I presume after validating the options, you’ll have to access them. Why not
combine the two? Something like:
[parentheses, other_option] = Keyword.fetch_exact!(opts, [:parentheses,
:other_option])
Perhaps even supporting defaults:
[other_option, parentheses] =
In my opinion, these are exactly the kinds of functions we should be
adding. They address common scenarios that make it easier on beginners, and
encourages the practices we want. +1from me.
-bt
On Wed, Dec 30, 2020 at 11:06 AM Greg Vaughn wrote:
> I really like the idea of a convenience
I really like the idea of a convenience function in the Keyword module. One
idea that comes to mind:
Keyword.limit_keys!([parentheses: 10], [:parenthesis])
raises or returns 1st param unchanged.
-Greg
> On Dec 30, 2020, at 4:53 AM, José Valim wrote:
>
> The issue is that for take!, I can see
The issue is that for take!, I can see two semantics:
1. The map/keyword must have all of the given keys
2. The map/keyword must have at most the given keys
And I think 1) makes more sense intuitively. :(
On Wed, Dec 30, 2020 at 11:48 AM Wojtek Mach wrote:
> Fair enough, agreed about
Fair enough, agreed about decoupling the problem. In that case I’d still offer
Keyword.take!/2 that works like this:
iex> Keyword.take!([a: 1], [:a, :b])
[a: 1]
iex> Keyword.take!([c: 1], [:a, :b])
** (ArgumentError)
I think take/2 and take!/2 matches struct/2 and struct!/2.
> On
Wojtek, I originally thought about Map.merge!, where the second argument
must be a subset of the first. This way we can check keys and provide
default values:
Keyword.merge!([parenthesis: 10], opts)
However, when I tried using this in practice, I realized that default
arguments are not always
Agreed with Andrea and Devon. And hopefully in the future that typo will be
caught by the compiler!? :)
On Wednesday, December 30, 2020 at 10:10:17 AM UTC+1 woj...@wojtekmach.pl
wrote:
> I think this would be a great addition to the core.
>
> While there are libraries in this space, as silly
I think this would be a great addition to the core.
While there are libraries in this space, as silly as this may seem, solving
this key typo problem seems like solving the 60%-80% case (not to take away
anything from those libraries!)
How about a Keyword.take!/2?
iex> Keyword.take!([a: 1],
Typos are extremely hard to prevent in dynamic data structures since
validations need to be implemented at the point of use instead of at the
point of creation/definition of the structure. What would stop the
developer from writing the typo in their validation, as José did in his
example?
It
Yes, but think of the valuable hours saved and the amount of code that
won't have to be written.
I mean even Valim's own example again has the typo.
On Tue, Dec 29, 2020 at 11:58 PM Andrea Leopardi
wrote:
> Considering how straightforward the code you showed is, and that for more
> complex
15 matches
Mail list logo
