Heretical thoughts: OOP with Elixir

So I’m reading a tutorial and it’s showing how to rebind a variable (a style I don’t like):

person = Map.put(person, :region, "west-1")

And it struck me how much it looks like de-sugared Python. I.e., with a theoretical OOP syntactic sugar layer, we could do this:

person.put(:region, "west-1")

IMO, that’s more concise and expressive. And the OOP syntax would simply the search for compatible functions. E.g., it could combine both List and Enum for lists.

So what are the arguments against this kind of object-oriented syntax? Is rebinding a slippery slope to difficult-to-understand code? What are the strengths of the more repetitive functional syntax? Is it the change in how we think about data and functions as separate?

Mutation

person.put(:region, "west-1")

vs. new value

person = Map.put(person, :region, "west-1")

at least in my mind.

1 Like

IMO the person.put syntax is deceiving, it can’t really “mutate” the thing it looks like it should. For instance (hypothetical, won’t compile):

person = %{region: "east-1"}
also_person = person
person.put(:region, "west-1")

# what is also_person.region?

person and also_person start out referring to the same Map, but then person is changed to refer to a different, updated Map. An OO-style mutation would result in also_person.region changing as well.

You could get close as-is with pipes and import:

import Map

person =
  person
  |> put(:region, "west-1")

or even (with the two-argument form of put_in):

person = put_in person[:region], "west-1"

The pipe syntax tends to lead to a lot of the “de-sugared Python” flavor, since it threads through the first argument.

Also worth reading the old discussions around “tuple calls” (Tuple Calls) which covers some similar conceptual space.

3 Likes

I don’t see anything Object Oriented in your question. It seems you want mutable data structures. Immutability is expected throughout BEAM code.

7 Likes