Allowing the object.method(args...) syntax as an alias for method(object, args ...)

[uniment]

@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 ...)

@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. @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.

(; 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 does work on modules, and supposedly they work on the same methods).

If it worked, @jlapeyre could write:

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

Wonderful syntax