Tuple Calls

[OvermindDL1]

@Qqwy

The difference between tuple calls and piping, and why I call this ‘OOP-style’ is that you are dispatching functions based on the data type you happen to have at hand:

It is identical to dispatching based on a module ID as well:

defmodule Blah do
  def send_message(msg) do
    send(NamedProcess, msg)
    Blah
  end
end

a = Blah
a.send_message(1).send_message(42).send_message(6.28).send_message("Hello world")

Just happens to be a function that returns the right thing in the right format, though in this case it is more obscure that a tuple call as it is obvious that push should be returning the updated structure, which it indeed does. Really though, if someone did that with different things that returned different tuples to different modules, that would be quite obscure and not recommended, but I do not even recommending doing that with pipes (when the type changes in pipes then I add intermediate bindings unless it is a trailing Enum.into/2 or something obvious like that).

It is not different then just calling a binding that has a module name bound to it, like a=IO; a.inspect(42).

@Qqwy

Here, which bar/2 is called depends on what my_data_type actually is bound to.

Yep, just like a=IO; a.inspect(42) does.

@Qqwy

This is the kind of implicitness inherent in OOP programs because in objects, code and data lives together, and exactly what we try to avoid in functional programming.

First class modules in OCaml are certainly not even remotely OOP, and yet this is exactly how it is implemented in OCaml as well (internally it is also a tuple of data, though it does not need to carry the first element ‘type’ along like Erlang’s tuple calls do since it knows the type already) and is a common pattern (standard way is to name it SomeName.S where S is the recursive module signature of that module).