# Allowing the object.method(args...) syntax as an alias for method(object, args ...)
**URL:** https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051
**Category:** Internals & Design
**Tags:** question, design
**Created:** [May 29, 2021, 5:09pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051 "2021-05-29T17:09:54Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [May 30, 2021, 5:19am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/22 "2021-05-30T05:19:24Z")
> [@gianmariomanca](#):
>
> @Raf can you write an explicit example of the ambiguity?
(Taking the example from above:)
```julia
mutable struct IIRFilter
state::Float64
alpha::Float64
end
julia> f = IIRFilter(0.5, 0.7)
IIRFilter(0.5, 0.7)
# This could of course be a much more complicated function, making use of `f.state`
julia> state(f::IIRFilter) = f.state
state (generic function with 1 method)
julia> f.state()
ERROR: MethodError: objects of type Float64 are not callable
Maybe you forgot to use an operator such as *, ^, %, / etc. ?
Stacktrace:
[1] top-level scope
@ REPL[20]:1
```
The problem arises when `f.state` _is_ callable - which call do you choose?
```julia
julia> struct Metafilter
filter::IIRFilter
end
julia> filter(m::Metafilter) = m.filter
filter (generic function with 1 method)
julia> (filter::IIRFilter)() = filter.state * filter.alpha
julia> m = Metafilter(f)
Metafilter(IIRFilter(0.5, 0.7))
# would you have expected this here? It's basically the same as (m.filter)(), which is (::IIRFilter)()
julia> m.filter()
0.35
julia> filter(m)
IIRFilter(0.5, 0.7)
```
---
### Author:  [@gianmariomanca](https://discourse.julialang.org/u/gianmariomanca)
#### Post date: [May 30, 2021, 5:22am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/23 "2021-05-30T05:22:42Z")
> [@Sukera](#):
>
> The problem of course is that you lose some sense of what each combination of arguments actually does. Moreover, you can’t distinguish between two methods with the same number of arguments and the same types of arguments but different behaviour this way.
This is what I was referring to when I mentioned “only one method”. I should have been more specific.
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 30, 2021, 5:35am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/24 "2021-05-30T05:35:50Z")
In Julia any object can be called like that.
```julia
julia> struct Callable end
julia> (::Callable)(x) = 2x
julia> obj = (a=Callable(), b=Callable())
(a = Callable(), b = Callable())
julia> obj.b(5)
10
```
So there is so syntactical distinction between fields and functions… anything can be called as a function.
---
### Author:  [@Eben60](https://discourse.julialang.org/u/Eben60)
#### Post date: [May 30, 2021, 4:42pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/26 "2021-05-30T16:42:39Z")
> [@Mason](#):
>
> This has really been discussed to death in a lot of different places, usually asked for by newcomers,
One recent thread [Is it reasonable to mimic a Python class with mutable structs?](https://discourse.julialang.org/t/is-it-reasonable-to-mimic-a-python-class-with-mutable-structs/57516)
---
### Author:  [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)
#### Post date: [May 30, 2021, 5:08pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/27 "2021-05-30T17:08:50Z")
> [@pdeffebach](#):
>
> The auto-completion is the hard part, and it seems like there are some serious efforts underway to make it easier.
This is the first I’ve heard of such efforts, do you have more information to share about them?
Good completion is probably the holy grail of editor tooling support in Julia land (alongside an integrated hoogle/`@which`/`methodswith` search). One avenue that might be interesting to explore is Intellij-style [postfix completion](https://youtu.be/jTud6GIqVgk?t=300), which would allow one to type something like `x.[ctrl+space]foo` but actually write out `foo(x)`. I noticed that there are [extensions](https://github.com/ipatalas/vscode-postfix-ts) that do this for VS Code, but I’m not sure if it’s possible to hook them into the language server or not.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [May 30, 2021, 5:41pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/28 "2021-05-30T17:41:58Z")
> [@gianmariomanca](#):
>
> (where IIRfilter is the first argument of the method if we are thinking about standard OOP, or maybe a more general solution that is closer in spirit with multiple dispatch?)
Probably this is implicit (or explicit) in the answers above, and I’ve missed it, but consider this example:
```julia
julia> struct A
x::Vector{Int}
end
julia> f(x) = x[1]
f (generic function with 1 method)
```
function `f` clearly does not work for type `A`, thus I suspect one would not want that given `a=A([1,2,3])`, typing `a.f(...` returned anything, or that `f` was listed in any list of methods that can be applied to type `A`.
Yet, if we do:
```julia
julia> Base.getindex(a::A,i) = a.x[i]
```
suddenly `f` is a function that can perfectly work for type `a`:
```julia
julia> f(a)
1
```
Thus, my impression is that while some subset of the functionality you propose can be obtained (methods that explicitly annotate type `A` for example), in general that will not be very useful, in particular if developers follow the more or less sensible guidelines that functions [should be type-annotated as flexible as possible](https://www.oxinabox.net/2020/04/19/Julia-Antipatterns.html) (see Over-constraining argument types).
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [May 30, 2021, 7:10pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/29 "2021-05-30T19:10:50Z")
> [@gianmariomanca](#):
>
> @Mason , thank you for welcoming me. I think it was a mistake on my part to bring up “barrier of entry”, it seems to monopolize the attention and bring the discussion in the unproductive direction of “this language vs that language”. I did it just because that episode with my colleague attracted my attention and seemed like a missed opportunity.
>
> In general my attitude in this comment was just “steal” as many good features as possible (which seems very much in line with the spirit behind Julia’s creation when the co-creators wanted it “all”.)
No problem, sorry if I ranted at you. I definitely agree we should be stealing good features! However, I think what I’ve been trying to argue and what others have been arguing is that the costs are greater than the benefits.
One other cost that hasn’t really been brought up yet is that julia already has a _lot_ of special syntactic forms that are hard for beginners to learn. We need to be conservative about adding more. I think it’s important to try and come up with _powerful_ syntax extensions that can be generalized to many situations, rather than adding more single purpose syntax.
> [@gianmariomanca](#):
>
> I think you might be misreading Bjarne Stroustrup comment. Yes I agree that is a bad idea to **always** assume that there is one “most-important” argument, but here we are talking about having more options, not less. Nobody wants to remove the standard notation, just adding a new equivalent one with some known advantages, in some of the cases. It’s up to people then to use the best one in each case.
>
> If you ask me doesn’t even have to be only the first argument, if better or more flexible you can make it that you can use the object.method notation when the object is in _any_ position.
> Let’s say you have object f of type IIRfilter and 2 methods m1(IIRfilter,x) and m2(y,IIRfilter) then you can say f.m1(x) and it will call m1(IIRfilter,x) and f.m2(y) and it will call m2(y,IIRfilter). Maybe allow this notation only for methods with no ambiguity, i.e. only one entry of that specific type, since this notation is targeting the “one most important object” case. Just added this comment for the sake of conversation.
Fair point. I guess though that as others have already pointed out, there’s a lot of potential for conflicts here between that names of properties and the names of methods laying around in the namespace that makes me very wary of this.
> [@gianmariomanca](#):
>
> In general would the way I wrote the IIRfilter example considered good “Julian”? How would you rewrite it? Wouldn’t x\_f = f.filter(x) look nicer in this case?
To my eye, I guess I’m just so used to julia that I don’t see what’s so nice about
```julia
x_f = f.filter(x)
```
and why I wouldn’t want to just write
```julia
x_f = filter(f,x)
```
which I think is visually much cleaner.
One other thing I should mention is that there are various proposals for a new anonymous function syntax so that writing `filter(_, x)` is equivalent to `f -> filter(f, x)`. That way, you could write
```julia
x_f = f |> filter(_, x)
```
if desired. I’m not sure this is a great win, but it’s being considered.
---
### Author:  [@DrChainsaw](https://discourse.julialang.org/u/DrChainsaw)
#### Post date: [May 30, 2021, 8:07pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/30 "2021-05-30T20:07:36Z")
Just because I’m bored. Don’t do this 🙂
```julia
macro bless(T, fs...)
fswitch = map(fs) do f
:(s === nameof($f) && return (args...;kwargs...) -> $f(t, args...; kwargs...))
end
quote
@eval Main begin
function Base.getproperty(t::$T, s::Symbol)
$(fswitch...)
return getfield(t, s)
end
Base.propertynames(t::$T, private::Bool=false) = private ? ($fs..., fieldnames($T)...) : $fs
end
end
end
julia> struct AA
x::Int
end
julia> f1(a::AA, x) = a.x + x
f1 (generic function with 1 method)
julia> f2(a::AA, x) = a.x * x
f2 (generic function with 1 method)
julia> f3(a::AA, x, y;z) = z*(a.x - x^y)
f3 (generic function with 1 method)
julia> @bless AA f1 f2 f3
julia> aa = AA(2)
AA(2)
julia> aa.f # type aa. and press tab
f1 f2 f3
julia> aa.f1(6)
8
julia> aa.f2(6)
12
julia> aa.f3(2,3;z=4)
-24
```
Yes, the name of the macro is a reference to a language which tucked on OO though it probably shouldn’t.
Anyways, I agree that one drawback with functions first is discoverability.
---
### Author:  [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [May 30, 2021, 10:11pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/31 "2021-05-30T22:11:08Z")
We should really add this it the FAQ
[https://docs.julialang.org/en/v1/manual/faq](https://docs.julialang.org/en/v1/manual/faq)
It would be good if someone could summarised this thread including the downsides and upsides, and make a PR to the docs.
---
### Author:  [@gianmariomanca](https://discourse.julialang.org/u/gianmariomanca)
#### Post date: [May 30, 2021, 11:30pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/32 "2021-05-30T23:30:41Z")
Thank you. Yes this was also apparent from @mcabbott example.
Still C++ has the same issue but that didn’t seem to be a sufficient reason to immediately reject the idea.
( PS One think I appreciate about Bjarne Stroustrup from the few talks I saw and the linked documents is that he is always very pragmatic and he seems to try to always look for the greater good. I’m not claiming I know what the greater good is, I just felt like complimenting Stroustrup 😃 )
---
### Author:  [@gianmariomanca](https://discourse.julialang.org/u/gianmariomanca)
#### Post date: [May 30, 2021, 11:33pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/33 "2021-05-30T23:33:16Z")
This seems to apply to any auto-completion effort including the one linked earlier in this thread ([https://github.com/JuliaLang/julia/pull/38791](https://github.com/JuliaLang/julia/pull/38791)). But I don’t think its a valid reason to give up on discoverability for the cases where it’s possible to have it. Unless I misunderstood your comment. In fact I would add the discoverability should be “smart” and whenever possible not too verbose.
---
### Author:  [@jzr](https://discourse.julialang.org/u/jzr)
#### Post date: [May 30, 2021, 11:35pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/34 "2021-05-30T23:35:19Z")
Nim describes its disambiguation procedure.
[https://nim-lang.org/docs/manual.html#templates-limitations-of-the-method-call-syntax](https://nim-lang.org/docs/manual.html#templates-limitations-of-the-method-call-syntax)
---
### Author:  [@NiclasMattsson](https://discourse.julialang.org/u/NiclasMattsson)
#### Post date: [May 31, 2021, 12:10am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/35 "2021-05-31T00:10:54Z")
Sometimes people travel halfway around the world to visit an exotic country, then spend the first afternoon asking the locals where they can find a decent hamburger restaurant. It’s understandable because it’s a safe choice (who knows what those crazy foreigners are cooking) but it’s also understandable that the locals are a bit saddened and try to convince the visitor to sample the local cuisine.
So please, have a taste, you may find it delicious. We have a vibrant culture with many master chefs who’ve developed some unique dishes over the years. Some visitors are so taken that they end up moving here permanently. And even if you’re not one of them, you may find when you get home that your tastes have broadened and you can cook burgers in exciting new ways.
---
### Author:  [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)
#### Post date: [May 31, 2021, 12:19am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/36 "2021-05-31T00:19:39Z")
> [@simeonschaub](#):
>
> ?(x, y)TAB completes methods accepting x, y by timholy · Pull Request #38791 · JuliaLang/julia · GitHub
See [this PR](https://github.com/JuliaLang/julia/pull/38791), linked to earlier in the thread.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [May 31, 2021, 12:33am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/37 "2021-05-31T00:33:09Z")
What I meant is that in principle all functions defined everywhere which do not have type annotations excluding the new type could be applied to a new type. This is what it makes possible I being able to define a new type of Matrix and use everything that is defined in base or other packages that define methods to work with matrices.
Some of them will not make sense and error, of course, but that possibility is one of the strength of multiple dispatch and general programming.
I am inclined to think that a package + macro that provided a list of methods the author of the type would like to be listed is a reasonable choice to improve the experience of the user in the sense OO programers are used to.
---
### Author:  [@gianmariomanca](https://discourse.julialang.org/u/gianmariomanca)
#### Post date: [May 31, 2021, 12:52am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/38 "2021-05-31T00:52:36Z")
@NiclasMattsson , I know it can be fun trying to come up “catchy” analogies, but I won’t take it personally since I’m the farthest thing you can find from the guy the eats hamburger in an exotic country 😉
To play your game, now that I think about it: there is a recurring discussion in Italy of how come Italy is not the first touristic destination in the world, and gets “beaten” by Spain, France, you name it… when on paper it could “win” against anybody by a huge margin (history, food, weather, music, friendly locals…). The reason is that they rely too much on their “intrinsic” value and ignore completely all organizational aspects that make a vacation pleasant and _not_ stressful. Sad, but true.
(PS just playing a game here, this comment doesn’t really matter for the overall informative discussion)
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 31, 2021, 1:38am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/39 "2021-05-31T01:38:32Z")
People here also seem generally pragmatic to me. If you see lack of pragmatism, hopefully you can imagine difficulties and tradeoffs that you dont yet see that are constraining the possibilities, rather than stubbornness!
Basically, we all want autocompletion, but its a hard problem. Largely because we also expect that thousands of loosely typed functions defined in packages we dont even know about (or are not written yet) will work on our objects. That’s a good problem to have, and C++ does not have it. It has the expression problem instead. But it clearly has some drawbacks, like autocompleting them all in a sane way.
I also write C++ and like autocompletion. But knowing both contexts, they are not equivalent and the problem is really more difficult in Julia. Im not sure what else there is to say.
---
### Author:  [@NiclasMattsson](https://discourse.julialang.org/u/NiclasMattsson)
#### Post date: [May 31, 2021, 9:29am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/40 "2021-05-31T09:29:59Z")
Glad you didn’t take my over-the-top analogy personally. We’re not resisting your suggestion because we’re against syntactic sugar or easier onboarding for pythonistas. The problem (as other have explained above) is that your proposed syntax would likely increase confusion for Julia beginners. The `object.method()` syntax explicitly indicates a hierarchy that simply does not exist in Julia. Better to make a clean break with syntax from other languages up front and get newbies using multiple dispatch ASAP. Its benefits are subtle and take time to grasp - a beginner may immediately note that it’s more powerful and expressive, but its [long-term advantages for the package ecosystem](https://www.youtube.com/watch?v=kc9HwsxE1OY) are not obvious.
EDIT: Initially got a different url from what I intended.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [May 31, 2021, 9:50am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/41 "2021-05-31T09:50:37Z")
> [@gianmariomanca](#):
>
> there is a recurring discussion in Italy
To stretch that analogy a bit, a lot of suggestions from newcomers or outsiders on how Julia should be redesigned (in a major or minor way) sounds like me going to Italy and telling them how to make pizza (disclaimer: I only have a vague idea about it; presumably it involves flour at some point).
Its not like Julia is perfect — far from it. But making meaningful suggestions about improving it at this point requires quite a bit of investment. This is how I understand @NiclasMattsson’s comment about “having a taste”: it may make sense to use Julia _as is_ for your first 50–100k LOC, and _then_ see what you are really missing. Chances are that the `obj.method` syntax won’t feel natural any more, but if it does, you will be in a much better position to argue for it.
---
### Author:  [@gianmariomanca](https://discourse.julialang.org/u/gianmariomanca)
#### Post date: [May 31, 2021, 1:24pm UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/42 "2021-05-31T13:24:59Z")
Guys, I appreciate the enthusiasm, the feedback and the suggestions, but going back to a more “academic” style of discussion, I would say I would be pretty impressed if the only thing that came out of it initially was a nice documentation page.
Let’s say titled “discovery and auto-completion in Julia” with:
- problem statement
- list of possible approaches, not necessarily mutually exclusive. From all-encompassing to minimalistic, with pros and cons: verbosity, ease of use, learning curve, etc and I would include stuff like the [Uniform Function Call Syntax](https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax)
- current attempts and lessons learned
- comparison with other languages and their solutions/approaches
- thesis proposal 🙂 “discovery and auto-completion in a generic programming language with multiple-dispatch”
[Previous page](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051.md?page=1)
[Next page](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051.md?page=3)