Provide different accessors in the Access module #4009

Closed
josevalim opened this Issue Nov 28, 2015 · 6 comments

Projects

None yet

4 participants

@josevalim
Member

The goal is to provide accessors to be used alongside Kernel.put_in and friends. For example:

put_in sample[:foo][:bar], :baz

Can be thought as a shortcut to:

put_in sample, [Access.key(:foo), Access.key(:bar)], :baz

Where Access.key(:foo) will return a function as described by Kernel.get_and_update_in. Similar would exist for structs:

put_in sample.foo.bar, :baz

is equivalent to:

put_in sample, [Access.field(:foo), Access.field(:bar)], :baz

For now, we will also provide all/0 and at/1 for lists and elem/1 for tuples. The question is the naming convention for those functions. For example, we could prefix most of them by by_: by_key, by_elem and by_field, although it wouldn't work for all/0 and at/1. Alternatively, we can drop the by_ prefix, although it could be confusing if mixed with the existing fetch/2, get/3 and friends.

Thoughts?

@tuvistavie
Contributor

Would it be possible to have some more info about this one?

@josevalim josevalim self-assigned this Jan 4, 2016
@josevalim
Member

I have updated the description although it is assigned to me. :)

@lexmag
Member
lexmag commented Jan 5, 2016

I think not having by_ prefix is completely fine: there is single "static" argument, feels natural with fetch/2 and get/3.

@josevalim josevalim modified the milestone: v1.3.0 May 13, 2016
@josevalim josevalim closed this in 464d3dd May 26, 2016
@amuino
Contributor
amuino commented May 28, 2016

Any reason why at was finally not added for lists? I found myself implementing first (which is just a particular case of at).

@josevalim
Member

No reason. Would you like to send a PR?

On Saturday, May 28, 2016, Abel Muiño notifications@github.com wrote:

Any reason why at was finally not added for lists? I found myself
implementing first (which is just a particular case of at).


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#4009 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAAlbqktmueRKfRyFu5L27KWPcaCEUZbks5qGKhXgaJpZM4Gq5o4
.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

@amuino amuino added a commit to amuino/elixir that referenced this issue May 29, 2016
@amuino amuino Implement Access.at/1
It was described, but not implemented, on #4009
0914614
@amuino amuino added a commit to amuino/elixir that referenced this issue May 29, 2016
@amuino amuino Implement Access.at/1
It was described, but not implemented, on #4009
d305cb4
@amuino
Contributor
amuino commented May 29, 2016

@josevalim Done! #4719

Would it be useful to have first and last? (Mostly because last is a bit cumbersome to implement with an index based API).

Re: naming, I'll throw an idea… Access.List.at, Access.Tuple.elem… (or maybe the other way around: List.Access.at…).

@amuino amuino added a commit to amuino/elixir that referenced this issue May 29, 2016
@amuino amuino Implement Access.at/1
It was described, but not implemented, on #4009
ef797be
@amuino amuino added a commit to amuino/elixir that referenced this issue May 29, 2016
@amuino amuino Implement Access.at/1
It was described, but not implemented, on #4009
1301fed
@amuino amuino added a commit to amuino/elixir that referenced this issue May 30, 2016
@amuino amuino Implement Access.at/1
It was described, but not implemented, on #4009
3b69639
@josevalim josevalim added a commit that referenced this issue May 30, 2016
@amuino @josevalim amuino + josevalim Implement Access.at/1 (#4719)
It was described, but not implemented, on #4009
953aac7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment