# Function discovery

**URL:** https://discourse.julialang.org/t/function-discovery/107652
**Category:** New to Julia
**Created:** [December 15, 2023, 10:04am UTC](https://discourse.julialang.org/t/function-discovery/107652 "2023-12-15T10:04:17Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [December 15, 2023, 10:43am UTC](https://discourse.julialang.org/t/function-discovery/107652/2 "2023-12-15T10:43:40Z")

</div>

This has been discussed many times!

See:

> [@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/119):
>
> That’s indeed useful, and pipes already give the ability. That often requires putting the “main” argument as the last function argument, not the first. Think of common data manipulation functions map/filter/mapreduce/etc: they wouldn’t be convenient with your proposal. Meanwhile, one can use a helper piping package, for example with DataPipes: @p X |\> filter(isodd) |\> map(log) |\> findmax(abs) @p "Hello, world!" |\> split(\_\_, ",") |\> replace.(\_\_, "o"=\>"e") |\> join(\_\_, ":") Autocomplete rela…

> [@Fixing the Piping/Chaining Issue](https://discourse.julialang.org/t/fixing-the-piping-chaining-issue/89654):
>
> Objective To satisfy Julia’s piping/chaining/currying/partial application problem with an elegant and functional approach worthy and idiomatic of Base Julia. If you want, skip the background reading material straight down to the proposal. Background Piping, chaining, threading—whatever people call it, it’s a very common thought pattern to take an object and pull it through a sequence of one or more transformations. In many contexts it’s most natural to think of the object first, and then to th…

> [@My mental load using Julia is much higher than, e.g., in Python. How to reduce it?](https://discourse.julialang.org/t/my-mental-load-using-julia-is-much-higher-than-e-g-in-python-how-to-reduce-it/18902/5):
>
> I think these are all reasonable points, but I hope I can help a little bit. I think what you’re talking about is “fluent interfaces”, and it’s true that we don’t really do that in Julia, at least not in the same way. You might find the |\> operator useful, since you can do: x |\> f |\> g as an alternative notation for g(f(x)). This should become even better when we (eventually) get [RFC: curry underscore arguments to create anonymous functions by stevengj · Pull Request #24990 · JuliaLang/julia…](https://github.com/JuliaLang/julia/pull/24990)

We cant just use `x.f` like that because the syntax is already taken - there can already be an object or a function field at `x.f`.

The Julia alternative is `methodswith(typeof(x))`. It will give you methods that match args at any position.

Yes, its kind of a pain compared to OOP tab completion, one of the very few downsides of using multiple dispatch.

---

_[View the full topic](https://discourse.julialang.org/t/function-discovery/107652)._
