# 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:** 1\
**Showing post:** 153

<div class="post-metadata">

**Author:** ![uniment](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/uniment/32/24532_2.png) [@uniment](https://discourse.julialang.org/u/uniment)\
**Post date:** [October 7, 2022, 4:53am UTC](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/153 "2022-10-07T04:53:35Z")

</div>

> [@Benny](#):
>
> Then you already lost me at using UFCS to mimic OOP syntax.

The main benefits to UFCS, IMO, have nothing to do with the object oriented paradigm. It’s just nice syntax that allows for noun→verb ordering, without being as limited as the pipe `|>`. Equating UFCS with OOP is a mistake imo. See this post:

> [@Allowing the object.method(args...) syntax as an alias for method(object, args ...)](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/118):
>
> @Mason, It’s particularly important to emphasize how Julia is not a single dispatch language, and the first argument to a function is not special. The do statement would say otherwise, but apparently we limit first-argument “specialness” to anonymous functions only. stuck_out_tongue_winking_eyethinkingpensive@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 her…

> [@Benny](#):
>
> In some OOP languages, you can access encapsulated functions `a = x.f` and call it later `a(y)`.

I’m not convinced that’s necessary. Encapsulation isn’t needed frequently, and an anonymous function can be explicitly defined when it is.

Use of `.` should be limited to property getting. Keep it simple.

> [@Benny](#):
>
> Concerning autocompletion based on the first type alone, it would only be performant with type properties/class encapsulation.

Macbooks are pretty powerful these days… I guess we’ll see. Likely more performant than my brain anyway.

> [@Benny](#):
>
> OOP programmers won’t like using anything but `.` for this; `..` is already pushing it and `--` will be a non-starter.

Not convinced. I prefer `+` for string concatenation and `*` for string replication, but Julia uses `*` and `^` respectively. It’s not the end of the world.

But also, it’s a beneficial reminder to OOP programmers that _this isn’t an OOP concept_; we are calling a _globally accessible method_ with the object as the first argument, \*not\* calling a method _that “belongs” to the object_. Hence why syntax other than `.` is good, to disambiguate for the compiler and also for the person between property getting and method calling.

But please, characters that are easy to type without errors. `|>` is such an error-prone sequence of characters.

> [@Benny](#):
>
> And the best for last, how would the parser tell if `x.f(y)` should be lowered to `f(x, y)` or if `x` really does have a callable field `f` accepting 1 argument?

That’s why I was proposing `..` to disambiguate from property getting. Or perhaps `--`.

> [@Benny](#):
>
> There is Chain.jl and Pipe.jl, they handle piping to any functions iirc.

Yes, there are about half a dozen packages that solve the same problem in slightly different ways, so we’re unlikely to have a standard anytime soon unless it’s incorporated into the language.

> [@Benny](#):
>
> I wouldn’t write all that, I’d sooner `import QCircuit as QC` and write `QC.x` everywhere.

Oh. Oh my. Oh my oh my. I just learned about Julia’s new destructuring syntax. 👏 👏 👏

```julia
(; prop1, prop2, prop3) = my_object # prop1 == my_object.prop1, etc.

```

Game. Changer. Sí se puede.

Strangely it doesn’t seem to work for destructuring modules… that seems like a bug (considering that [my destructuring code above](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051/150) _does_ work on modules, and supposedly they work on [the same methods](https://discourse.julialang.org/t/destructuring-syntax-in-julia-1-7/68236)).

If it worked, @jlapeyre could write:

```julia
let (; x, y, z) = QCircuit
    add!(circ, x, 1)
end

```

Wonderful syntax 🤌

---

_[View the full topic](https://discourse.julialang.org/t/allowing-the-object-method-args-syntax-as-an-alias-for-method-object-args/62051)._