Because:
- The intent is not to treat functions as properties of types. This isn’t an OO language!
- What is desired is not piping restricted to single-argument functions. We already have that and it sucks.
- What is being discussed is a language feature to support common thought patterns, not a dozen different libraries and macros that solve the problem in different ways and that will never become a standard.
CBOOCall is hoping to solve a very specific problem: allowing functions or objects with very short names (e.g. x
, y
, and z
) to be conveniently accessed from a module without polluting the global namespace. It’s spiffy, but not what we’re discussing. At least not what I’ve been.
But if we were trying to address that, @jlapeyre could’ve just used Julia’s let
statement. Using CBOOCall’s example:
using QCircuit # don't export x, y, and z
let x=QCircuit.x, y=QCircuit.y, z=QCircuit.z
add!(circ, x, 1)
end
This could be more convenient if Julia had some methods for object destructuring… or maybe for broadcasting access of properties, for example
..(obj, props::Tuple{Vararg{Symbol}}) = getproperty.(Ref(obj), props)
using QCircuit
let (x, y, z) = QCircuit..(:x, :y, :z)
add!(circ, x, 1)
end
Or even, maybe Julia could do something in the same spirit as JavaScript’s with
statement, to create a block where that namespace applies and outside which it doesn’t… perhaps
with QCircuit
add!(circ, x, 1)
end
Then any objects and methods of the QCircuit module would be available, but only within that block. I’ve seen some gnarly Julia code where this feature would substantially reduce code complexity and interdependence.
… Anyway, I digress.
Ah. Unfortunate.
Very well.
I guess --
isn’t being used for anything. Maybe?
my_object--mymethod()
has a ring to it
Some other possibilities: **
, ||
,
(Although I’d prefer ||
to be reserved for an operator with same precedence as addition, but sacrifices must be made)
We’re already on 1.8… queue meme of scheming raccoon