Immutable objects at last!

3 views
Skip to first unread message

Tony Arcieri

unread,
Jun 5, 2010, 11:38:28 PM6/5/10
to Reia Mailing List
(This message is shamelessly copied from my blog.  You can view the original post here: 

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)
=> #
>> 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
This is similar to the state management compromise Rich Hickey chose in the Clojure language.  In Clojure, by default all state is immutable.  However, Clojure employs Software Transactional Memory for concurrency, and inside of Clojure's STM transactions (i.e. where concurrency enters the picture) state becomes mutable.

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!


--
Tony Arcieri
Medioh! A Kudelski Brand

Phil Pirozhkov

unread,
Jun 6, 2010, 2:55:38 PM6/6/10
to re...@googlegroups.com
Congratulations!

BR,
Phil

-----Original Message-----
From: Tony Arcieri <tony.a...@medioh.com>
To: Reia Mailing List <re...@googlegroups.com>
Date: Sat, 5 Jun 2010 21:38:28 -0600
Subject: [reia] Immutable objects at last!

> (This message is shamelessly copied from my blog. You can view the original
> post here:
> http://www.unlimitednovelty.com/2010/06/reia-immutable-objects-at-last.html)
>
> 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 <http://www.sics.se/~joe/bluetail/vol1/v1_oo.html>.


> 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<http://github.com/tarcieri/reia/commit/59650a160daecd1179105f8b2c2a143d371d31e3>.


> You can view an example of Reia's immutable

> objects<http://github.com/tarcieri/reia/blob/master/test/core/object_test.re>


> 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)
> => #
> >> 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<http://www.erlang.org/doc/design_principles/gen_server_concepts.html>,


> 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


>
> This is similar to the state management compromise Rich Hickey chose in the

> Clojure language <http://clojure.org/state>. In Clojure, by default all


> state is immutable. However, Clojure employs Software Transactional

> Memory<http://en.wikipedia.org/wiki/Software_transactional_memory> for


> concurrency, and inside of Clojure's STM transactions (i.e. where
> concurrency enters the picture) state becomes mutable.
>
> 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<http://github.com/tarcieri/reia> 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<http://github.com/tarcieri>)


> 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!
>
> --
> Tony Arcieri
> Medioh! A Kudelski Brand
>

> --
> You received this message because you are subscribed to the Google Groups "Reia" group.
> To post to this group, send email to re...@googlegroups.com.
> To unsubscribe from this group, send email to reia+uns...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/reia?hl=en.
>
>
>

Reply all
Reply to author
Forward
0 new messages