@p @j @Junes @SilverDeth @lanodan @ElDeadKennedy @ceo_of_monoeye_dating

>The optimal way to do this, the way Elixir wants you to do it, is to factor it out and use a conditional and unless both clauses are trivial, you make another function; likely, you skip the conditional and you lean on pattern-matching...

I think that's a fair replacement for early return. If you do it correctly the complexities get resolved elsewhere and all that is left is a descriptive function name and you shouldn't need to care about how it is done. It does have an OOP abstraction smell to it though. That's the point of the `maybe`s, sometimes coupled with the `do`s; do this for me if it should be done, ignore when it shouldn't, I don't care about the details. It tends to remove the 20+ line if/switch statements you get in something like C when you need to do this and avoids dealing with fallthroughs in switch-case. And removes some noise from the function making it more readable/understandable. Of course, there are times where the 20 line case/cond is also more appropriate in Elixir.

>So you have named the branches `do_binary` and `do_asdf` but you actually do see a lot of things like that in the only Elixir codebase I'm familiar with

Kinda, you don't have to do that when the handling is simple like extracting something from a map or a list in a few lines. Arguably if it is more than a couple (10-15+) lines, you should make a function for it anyway. The example I gave above isn't really ideal since I would try hard to not write it. It is terrible design to process multiple types of something in a single function. If it really needs to exist, multiple functions guarded with a when are slightly better at least in my mind.

>fetch_and_contain_remote_object_from_id

You would name that function the same in other languages, because it's basically an entrypoint that does it all, an internal pseudo API. Unless you wouldn't write it all and wrote the same handling multiple times which is worse. Or caught the libc string manipulation function naming disease and called it robjfc_id or whatever. Hello vsnprintf and suckless function names that mean almost nothing at a glance.

>It's possible to think this is a reasonable wart, I'm sure, but it's really ugly to me,

It's a different code style basically. Same endless arguments about different code styles being better than others apply here as well.

>I'm not sure what you mean to convey. I do know how you do those things in this language;

Just that you can also do this, nothing more:
# Bleh, multiple types.
cond do
is_map(var) ->
var["some_property"]

is_list(var) ->
var[:different_property]

is_binary(var) ->
var
end