OOP-like dot notation in Julia

[bertschi]

100% agree with @Benny that solutions like obj.<tab> which work fine with class based OOP languages are not a good fit for Julia (which for good reason imho is not OOP). Instead, we need to be open for other and potentially totally different solutions. For inspiration, Haskell has Hoogle allowing to search for functions by type signature. Again, this is most likely not directly transferable to Julia which is much more dynamic and less reliant on strict type signatures … admittedly, the best solution for Julia has not been found yet, but good building blocks like methodswith, JET etc are are already there and could be better integrated. I’m convinced though that the solution will not be retrofitting obj.<tab> in some way?!?

[co1emi11er]

@bertschi

100% agree with @Benny that solutions like obj.<tab> which work fine with class based OOP languages are not a good fit for Julia (which for good reason imho is not OOP). Instead, we need to be open for other and potentially totally different solutions.

I agree as well. The obj.<tab> syntax doesn’t seem to mesh well with julia. I do think obj |> <tab> (if pipe had more capabilities) and ?(obj <tab> provide use cases for both ways of writing julia code.

@Benny

I don’t expect dependents to be able or willing to take the maintenance burden of extending Inventory’s list of important methods, and I don’t want to see other package’s methods mixed in any more than people would want functions outside classes to be listed among member methods.

The @lsp ::MyType = [foo, bar, baz] idea was just trying to imagine a way to get that manual support if you truly didn’t want to write an explicit method in your codebase. The more I think about the idea though, the more I like it due to the fact that this can live in your package/script and not the maintainers. It doesn’t have to look like the syntax above. It could even be in a .toml or .json file.

The main idea with this is I can tailor lsp to show functions for my needs. So yes you get the function list after tab for the explicit functions (you will then see explicit methods after you type out said function), but like you said

@Benny

“what methods in this other package could I try this type in?”

I think this allows me to do that discovery/navigation and then document it for myself to use and benefit from the lsp. Because I often forget and I have to rediscover and navigate again.

I think this also simplifies things a bit. Everyone gets a nice function list for the object on <tab> for the explicit functions. The other functions that you want are not free, but you can get them added how you want.

Thoughts?

[jlapeyre]

I misremembered above. In fact, I did add a feature to allow rearranging the order of the arguments. To get the order that Python uses for split, you do this:

julia> using CBOOCall
julia> @eval Base import CBOOCall;
julia> @eval Base CBOOCall.@cbooify String (split = (x, y) -> split(y, x),);
julia> "a,b,c".split(",")
3-element Vector{SubString{String}}:
 "a"
 "b"
 "c"

To use the original order of the Julia method, you do:

@eval Base CBOOCall.@cbooify String (split,)

and then ",".split("a,b,c")

This is not meant to be a useful example. In fact, it’s an example where the natural ordering of arguments is not clear.

I still haven’t decided on what new name, if any, to choose. I’d like to hear opinions, although this thread may not be the best place.

I pushed a repo that changes the name to DotCall.jl
Here is the original CBOOCall.jl (it has more tests and minor corrections.)

DotCall is more descriptive. But “@cbooify” somehow seems “punchier” than “@dotcallify”.

[ufechner7]

Did you register the package?

[jlapeyre]

CBOOCall is registered. The new one DotCall is not registered. I am considering registering it and deprecating CBOOCall.