Get rid of the Access protocol

[josevalim]

foo[...] should use the Dict API instead.

Because the Access protocol relies on the code server in development and test mode (when protocol consolidation is not applied), we have heard multiple reports of the system suffering greatly in performance as the code server becomes a bottleneck with multiple processes. This happens because the Access protocol ends up being invoked thousands of times and there isn't much we can do to improve it (in contrast to the Enumerable protocol where most of the list cases are inlined).

The decision has then become to limit the scope of the Access protocol to work only with dictionaries (i.e. entities that implement the Dict behaviour).

Since we are treating this as a performance bug, v1.1 will include a deprecation to the Access protocol (but they will still work). The implication is that we will need to add get_and_update to the Dict API.

[Kabie]

Will foo[...] works out of box for structs?

[josevalim]

No, it will work only for dictionaries.

[whatyouhide]

I'd love to try and work on this. A couple of questions:

• Access provides a get/2 function while Dict provides both get/2 and get/3. Would it be fine to just use Dict.get/2 in functions like Kernel.{put,get}_in and friends? I guess it makes sense since implementations of Access.get/2 have to return nil when the key is not found in the container.
• The Access protocol only specifies get/2 and get_and_update/3, but the implementation of Access for maps also defines a get!/2 function (defined here). A quick grep in the source of Elixir shows that that function isn't called anywhere. Should we nuke it?

I'll post other questions here if I bounce into something I need help understanding :).

[josevalim]

We shouldn't do anything now regarding this issue. All we are going to do
for 1.1 is emit a warning if someone, besides ourselves, implement the
protocol and add get_and_update to the Dict behavior. :)

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Lead Developer

[whatyouhide]

Oh, ok! I'm not sure how I would implement the warning (I mean, on my feet I can't come up with a good way to emit a warning if someone defimpls the Access protocol while still not emitting the warning when the protocol is defimpled in the core library).

As for Dict.get_and_update, I'd be glad to give an implementation of it a shot. Maybe we can just @doc false it so that we have it ready to go but no one will actually use it.

[josevalim]

We should just hardcode inside Protocol the Access protocol and skip the
warning if it is an Atom, List, Map or HashDict.

About get_and_update, there is no need to make it @doc false as it is going
to be part of the Dict API.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Lead Developer

[jemc]

Will there be a non-deprecated way to delegate the container[key] syntax to a custom function for a given module/struct?

The most common use I have for this behavior is delegating the access syntax to an inner map of attributes with arbitrary keys that I don't know at compile time:

defmodule Foo do
  defstruct bar: nil, baz: nil, attributes: %{} 
end
defimpl Access, for: Foo do
  def get(%Foo { attributes: attributes }, key) do
    attributes[key]
  end
end

foo = %Foo { bar: 88, baz: 99, attributes: %{ "some_key" => "some_value" } }
IO.inspect foo.bar #=> 88
IO.inspect foo.baz #=> 99
IO.inspect foo.attributes["some_key"] #=> "some_value"
IO.inspect foo["some_key"] #=> "some_value"

Will there be a non-deprecated way to do this?

[josevalim]

No. Or you need to implement the Dict api for it or it won't work.