When I started creating Reia, I was originally skeptical of the "everything is an object" concept seen in languages like Smalltalk and Ruby. This was partially inspired by Erlang creator Joe Armstrong's hatred of object oriented programming. However, the more I used Erlang and increasingly saw Erlang's solutions for state encapsulation like records and parameterized modules as increasingly inadequate, the more I looked to objects to provide a solution.
Moments ago I committed the remaining code needed to support instance variables within Reia's immutable objects. You can view an example of Reia's immutable objects in action. If you're familiar with Ruby, you'll hopefully have little trouble reading this code:
>> class Foo; def initialize(value); @value = value; end; def value; @value; end; end=> Foo>> obj = Foo(42)=> #<Foo @value=42>>> obj.value()=> 42
One caveat: Reia uses Python-style class instantiation syntax, i.e. Foo(42). Rubyists should read this as Foo.new(42).
So what are immutable objects, exactly? They work much like the traditional objects you're used to using in Ruby. Howevever, unlike Ruby, Reia is an immutable state language. This means once you create an object, you cannot modify it. The constructor method, which borrows the name "initialize" from Ruby, has the special ability to bind instance variables within a particular object, however once that initialize method completes and the object is created, no changes can be made. If you want to modify the instance variables, you'll have to create a new object.
Reia will eventually support objects whose state is allowed to change. These will take the form of concurrent objects, which is the original design goal I had in mind with Reia. Mutable objects take the form of Erlang processes, and more specifically Erlang/OTP gen_servers, which do not share any state with other concurrent objects and communicate only with Erlang messages. Going forward, my goal is to make all of the Reia built-in types into immutable objects, allowing user-defined immutable objects, and also allowing concurrent objects whose state can change (albeit in a purely functional manner).
If you've been following me so far, I hope you can sense how concurrency affects Reia's state management model:
- Sequential objects have immutable instance variables
- Concurrent objects will have mutable instance variables
There's still a lot to be implemented in Reia's object model. I intend to support polymorphism through simple class-based inheritance, and the code needed to support that is partially in place. I'd like to support Ruby-style mix-ins. Once these features are all in place, I intend to completely rewrite the core types, reimplementing them all as immutable objects.
All that said, if you're interested in Reia and would like to start hacking on it, Reia could really use a standard library of objects, and the requisite code is now in place to facilitate that. I would encourage anyone with an interest in Reia to clone it on github and start implementing the standard library features you will like. The standard library needs all sorts of things, particularly wrappers for things like files, sockets, ETS tables, and other things which are already provided by the Erlang standard library.
Don't worry too much about making mistakes. Just send me a pull request and I'll incorporate your code, review it, and make changes where I see issues. I'd like to prevent the standard library from snowballing into the monster the Ruby standard library is presently, so if you have a feature you'd like to see incorporated, ping me on it (through github is fine) and I'll let you know if I think it should be incorporated.
I'm actively trying to recruit the open source community to build Reia's standard library, so if you're interested, start hacking!