Imagine Ruby, if you had to explicitly namespace every method call with the mix-in that contains the method, so that 1. there could never be collisions between method names, and 2. finding mix-in method definitions at compile time was context-free. It'd maybe look a bit like this:
> 4.Integer::even?
=> true
Just chew the syntax a bit, and that's Elixir's:
> 4 |> Integer.even?
=> true
Mind you, that has nothing to do with "everything is an object." An object is—in the original Lisp+Smalltalk sense—effectively:
1. a stateful closure,
2. which you call with args representing a "message" to send to the object,
4. where the object is free to respond to that message however it likes—i.e. you can code the closure-that-is-the-object however you like—and its responses can depend on its state, meaning that the messages it responds to, and even its internal logic, can mutate over time, as this state changes.
Well, we've got plenty of "objects" in Erlang/Elixir land. We call those "processes." And they are cheap enough that—if you wanted—you could code in an "everything is a process" style. Presuming we defined two modules, ObjectFactory and Object, as GenServers with the requisite functions:
{:ok, obj_f} = ObjectFactory.start_link
foo = obj_f |> ObjectFactory.make_object!
foo |> Object.extend(:bar, fn -> 3 end)
foo |> send(:bar)
# => 3
All Object.extend/2 needs to do its job is to store something in the GenServer's state, and to rely on Object's GenServer.handle_info/2 callback to do something with that state.
Now, mind you, this won't magick a Bar module into existence to make this API pretty. But there's nothing stopping you from defining one yourself—or even from creating a Mixin module that you could Kernel.use/1 in your mix-in modules, giving them an API Object.extend/1 could understand, and giving you the ability to:
foo |> Object.extend(Bar)
foo |> Bar.bar