# Dictionaries of String =\> Any or Symbol =\> Any , dot notation

**URL:** <https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605>\
**Category:** Internals & Design\
**Tags:** proposal\
**Created:** [November 28, 2016, 10:10am UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605 "2016-11-28T10:10:43Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![TsurHerman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsurherman/32/1234_2.png) [@TsurHerman](https://discourse.julialang.org/u/TsurHerman)\
**Post date:** [November 28, 2016, 10:10am UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/1 "2016-11-28T10:10:44Z")

</div>

I understand that there are many implications to consider when promoting  
getfield from Core to Base (which will allow overloading of the dot operator)

But I thing at least for dictionaries with keys either symbol or strings it is safe  
to add this convenience.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [November 28, 2016, 5:48pm UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/2 "2016-11-28T17:48:38Z")

</div>

How does one statically know whether the argument is a dictionary or not?

Hopefully you’ve read [https://github.com/JuliaLang/julia/issues/1974](https://github.com/JuliaLang/julia/issues/1974) and made an attempt to grok the issues involved.

---

<div class="post-metadata">

**Author:** ![TsurHerman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsurherman/32/1234_2.png) [@TsurHerman](https://discourse.julialang.org/u/TsurHerman)\
**Post date:** [November 28, 2016, 7:24pm UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/3 "2016-11-28T19:24:11Z")

</div>

Yes I have read most of the discussion , personally I like best mauro’s proposal  
to fully promote getfield and to even allow additional arguments

> getfield(x::MyType, ::Field{:foo}, args…)  
> for example in : A.size(1)

But the complex debate that went on afterwards convinced me to settle for less 🙂

I was thinking of adding the following behavior to Core and to let multiple dispatch do its magic …

```julia

function setfield!{T}(value::Dict{Symbol,T},name::Symbol,x::T)::T
  value[name] = x
end
function setfield!{T}(value::Dict{String,T},name::Symbol,x::T)::T
  value["$(name)"] = x
end

```

maybe even limit that further  
and force T to be of type Any so only general purpose dictionaries will have this privilege

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [November 28, 2016, 10:04pm UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/4 "2016-11-28T22:04:05Z")

</div>

The biggest problem, as @jeff.bezanson points out in that thread, is that we have to make sure that actual field access and module-qualified access to globals both remain predictably efficient. Introducing the ability to overload the syntax at all, makes that hard, no matter how limited use you make of the ability. That said, if you feel like taking a crack at implementing this and manage to do so without causing performance regressions, that would be excellent.

There are second order concerns about what effect such overloading would have on how people use the language, but that’s not a showstopper.

---

<div class="post-metadata">

**Author:** ![akis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akis/32/156_2.png) [@akis](https://discourse.julialang.org/u/akis)\
**Post date:** [November 29, 2016, 6:26am UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/5 "2016-11-29T06:26:33Z")

</div>

Sometimes a third-order concern (like breaking some subtle form of consistency) can be of greater importance in the long term.

Changing a widespread behavior (here accessing instance’s fields) of an operator (here the dot) on an existing type (here the built-in type `Dict`) would be unfortunate, as it would violate the **“principle of least surprise”** (and also make debugging harder). Doing so at the language level as a privilege for exceptional cases would be even worse (multiple dispatch is meant for specialization, not for hacking) and I’m glad that design decision makers in Julia (despite individual developers’ shortsightedness at the time) have generally resisted the temptation of adopting things promoted merely for their easiness/safety/convenience, while lacking **strong justification** (and especially early in the development).

The ability to overload something as basic as the dot operator is telling of a language’s power to give its programmers more freedom of choices (so it would be nice to have), but “with freedom comes responsibility”. Extending the language shouldn’t be breaking existing behavior, so in present topic’s case I vote for the usage of a **separate operator**.

---

<div class="post-metadata">

**Author:** ![andyferris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andyferris/32/235_2.png) [@andyferris](https://discourse.julialang.org/u/andyferris)\
**Post date:** [November 29, 2016, 11:14am UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/6 "2016-11-29T11:14:06Z")

</div>

My concern here would be having such behavior as a special case for a few inbuilt types. One of the most brilliant parts of Julia is how most the language is written in Julia itself, and is extensible via multiple dispatch. Wouldn’t having this a special case be a step backwards?

---

<div class="post-metadata">

**Author:** ![barche](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/barche/32/79_2.png) [@barche](https://discourse.julialang.org/u/barche)\
**Post date:** [November 29, 2016, 1:26pm UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/7 "2016-11-29T13:26:53Z")

</div>

> [@akis](#):
>
> Changing a widespread behavior (here accessing instance’s fields) of an operator (here the dot) on an existing type (here the built-in type Dict) would be unfortunate, as it would violate the “principle of least surprise”

To me, not being able to overload `getfield` and `setfield!` actually came as a surprise. That said, I think in the end it may be best to stick with the current behavior to avoid performance problems and mysterious side effects. What would be useful is to standardize on a macro approach to the problem, as in the [DotOverload.jl](https://github.com/sneusse/DotOverload.jl) package, for example. I would like to see this functionality in Base, and refer to it in the documents about field access. The presence of the macro will alert the reader of the code to the fact that something non-standard is happening, and having the macro in Base makes sure everybody understands its purpose.

---

<div class="post-metadata">

**Author:** ![akis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/akis/32/156_2.png) [@akis](https://discourse.julialang.org/u/akis)\
**Post date:** [November 29, 2016, 2:57pm UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/8 "2016-11-29T14:57:53Z")

</div>

> [@barche](#):
>
> > [@akis](#):
> >
> > Changing a widespread behavior (here accessing instance’s fields) of an operator (here the dot) on an existing type (here the built-in type Dict) would be unfortunate, as it would violate the **“principle of least surprise”**
> 
> To me, not being able to overload getfield and setfield! actually came as a surprise.

It is a surprise, but less of a surprise than a dot accessing an element (think of `myarray.2`) instead of a field. That’s the meaning of “least”, not to remove all surprises (of course the point of reference to label something as surprise is not someone’s past, but the language used, here Julia). If a language tried to remove all surprises, then it wouldn’t be surprisingly pleasant to use.

---

<div class="post-metadata">

**Author:** ![TsurHerman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsurherman/32/1234_2.png) [@TsurHerman](https://discourse.julialang.org/u/TsurHerman)\
**Post date:** [December 12, 2016, 8:04am UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/9 "2016-12-12T08:04:33Z")

</div>

I started hacking away directly on the source code … I manage to get everything compiling and working.  
How can do performance regression tests? is there a ready made script that performs that and outputs to some log file?

Thanks,  
Tsur

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [December 12, 2016, 9:55am UTC](https://discourse.julialang.org/t/dictionaries-of-string-any-or-symbol-any-dot-notation/605/10 "2016-12-12T09:55:59Z")

</div>

See [https://github.com/JuliaCI/BaseBenchmarks.jl](https://github.com/JuliaCI/BaseBenchmarks.jl)