Want OOP in Elixir?



Are you tired of all of that modules, processes and functions nonsense? Do you want to just use classes, objects and methods? If so, use OOP [1] library in Elixir [2]!

[1] Actually, according to Alan Key, the inventor of OOP, “objects” is the lesser idea; the big idea is “messaging”. In that sense, I can’t agree more with Joe Armstrong’s quote that Erlang is “possibly the only object-oriented language”.

[2] Please don’t. You’ve been warned.

import OOP

class Person do
  var :name

  def say_hello_to(who) do
    what = "Hello #{who.name}"
    IO.puts("#{this.name}: #{what}")

joe = Person.new(name: "Joe")
mike = Person.new(name: "Mike")
robert = Person.new(name: "Robert")

joe.say_hello_to(mike)    # Joe: Hello Mike
mike.say_hello_to(joe)    # Mike: Hello Joe
mike.say_hello_to(robert) # Mike: Hello Robert
robert.say_hello_to(mike) # Robert: Hello Mike

joe.set_name("Hipster Joe")
joe.name # => Hipster Joe



The ability to troll other people is unlimited! :smiley: I love it.


This is absolutely amazing. The next step is a Ruby cross-compiler!

All joking aside, my mind is blown by how much you can do with Elixir’s metaprogramming features. Thank you for sharing!


Or @wojtekmach you could bite the bullet and actually learn FP on its own terms. :slight_smile: To abuse an analogy, stop trying to ride two horses at once. Eventually you’ll fall off and they’ll trample you.



Hey Onorio, not sure if you’re meta-trolling but this library is supposed to be a joke :slight_smile:


Ah–ok, then disregard my reply. Didn’t realize you were joking. :slight_smile:


How do I implement static methods using this library? Or should I create a Singleton instead? Or maybe use some sort of dependency injection? :smile:


@pablo static methods are not supported yet but PRs are welcome :smiley:


Jokes aside , Combining OOP and Functional programming has advantages in a select few cases.
I had a lot of fun with swift in that regard. (you could possibly do it in JS as well , but no … just no )


Actually I would not consider this idea as a joke, even if the above implementation is one: have You ever read The Art of the Metaobject Protocol?


@bsmr you have quite successful OO with classes or prototypes implementations in languages that do not support it out there. This is simply a matter of syntatic sugar and mechanisms built into the language, that make it easier.

GObject in C is good example, it is heavily used in Linux world.

Open question remains if binding data with functions together is such a great idea. Personally I think it impedes ability to use functional programming style. It also encourages you to create functions that have side-effects, rather than transforming the data in visible, clear manner. Not to mention that majority of OO implementations are also promoting mutable data structures.


I’ve been thinking about this a lot lately. I had a discussion about this (e.g. the never-dying OOP vs FP – which is better argument.) yesterday with a colleague. My current state of mind:

  • OOP and (Actor-Model-based) Functional Programming allow for a similar amount of abstraction and conciseness in programs.
  • The features in (Actor-Model-based) Functional Programming (immutability, pattern-matching, real concurrency without deadlock-dangers) allow you to write programs that are much faster than the alternative in OOP-programs.
  • There are a lot less ways in (AM-based) FP to shoot yourself in the foot than in OOP, because patterns like Demeters Law or tell, don’t ask resolve themselves naturally when working with processes/immutability.

I don’t remember who, but someone showed me this image a while back:

Basically, there are less patterns to learn, because most problems we face in Object-Oriented design resolve themselves in the functional world.

The hardest thing is to change your mindset from a I have this data and I want to put them in a hierarchy of objects to I have this data and I want to write functions/processes that consume it.

Of course there are nice features like Polymorphism, that some claim only exist in OOP-land, but I’d argue that that isn’t true; In Elixir we have Behaviours and Protocols to fill this gap, and they work great at allowing code-re-usage and ‘swapping out components’.




HAHAHA Very funny, and pretty awesome!


I really wonder if Ruby could be rewritten in Elixir. You could argue that Ruby’s biggest problem is lack of concurrency. Would this solve the problem? :smiley:


It’s very nice that you wrote this library, but it’s totally inappropriate to use :slight_smile:
Luckily Elixir is not Scala :wink:


Ruby has many features that make it flexible to use (and easy to shoot yourself in the foot with in the long term), but which mean that there is a lot of metadata to keep track of, which makes the language quite a bit slower. Also, these features go against the concurrency-principles in Elixir. What would happen, for instance, if you would load monkeypatched code in one ruby thread?

So while it is doubtlessly possible to build a Ruby intserpreter on top of Elixir, a lot of Elixirs nice features are lost because it will have to support Ruby’s design choices that go against it.


I learned from José’s keynote at the first ElixirConf that Elixir was originally a prototypal OO language on the BEAM – closer to Ruby and Javascript. But, yes, it performed poorly and he went a new direction, bringing us the Elixir we know and love today.