The issue with the static access operator (the dot)

Direct field access does irk me about every time I use it because I know it is doing a hidden function call behind the scenes, if there was truly unique syntax for accessing each thing unambiguously that could be properly inlined, I would be significantly happier, plus I’d not have any worry of handling the wrong things, though then this becomes “Why don’t we add types so you know you are accessing something that actually exists at compile time instead of just praying”, and etc… slippery slope (sudden urge to work on ElixirML some more, blehg too busy with work projects)…

EDIT: Also, I know you can override some Access.* things, is get one of them? If so you can override access that way…

@OvermindDL1 The Access protocol has

• fetch(container, key) (get value for key from structure, return success tuple).
• get(container, key, default) (get value for key from structure with default if it does not exist).
• get_and_update(container, key, function) (call function on value found for key if it exists, depending on the result possibly mutate container).
• pop(container, key) (remove key and its value from the container).

I do wonder what happens when the static access syntax is compiled. It might actually be inline-able to some extent. (Either at the Elixir → Erlang or at the Erlang → BEAM level).

I’m a bit confused, what is “direct field access” here, foo.bar ? If that’s what you mean it isn’t really a function call, IIRC it translates to basically:

case foo do
  %{bar: val} -> val
  _ -> apply(foo, :bar, []) # or an error handling clause, can't recall
end

foo[:bar] However is a function call Access.get which you can see easily from quoting it:

iex(1)> quote do: foo[:bar]
{{:., [], [Access, :get]}, [], [{:foo, [], Elixir}, :bar]}

I don’t believe any fancy inlining happens there.

The most important things to remember:

foo.bar # strict access, throws error if key doesn't exist
foo[:bar] # dynamic access, returns nil if key doesn't exist

So:
dots for structs
square brackets for keyword lists
both for maps

@PatNowak You are mistaken, the dot operator will fail at runtime for both structs and maps (and not at compiletime).

I think he meant that dot access is statically ‘called’ and bracket access is dynamically ‘called’, but yeah the terms could have been more clear.

@Qqwy Thanks, fixed
I meant that strict access is called in compile time, because it checks whether key exists in map /struct or not. It helps a lot to ensure that data is valid in terms of the content.

I usually use dots when dealing with structs and square bracket access when dealing with maps - especially in case and if statements.

But this isn’t the case. Nothing at all happens at compile time to ensure that the key does or does not exist in the map, nor even that foo is a map.

I’d love to hear more opinions about this.

One of the things I am considering right now, is to create a small library that adds overridable functions to a module that defines a struct, to access all struct fields instead of using .fieldname, so these access methods can be changed in the future.

How would it be different then just making a struct field by an anonymous function, just saving the . part of the invocation to become blah.vweep(42) instead of blah.vweep.(42) or so?