Immutable Ruby

ruby-talk
1

I was thinking about Erlang a bit today, the fact that it's objects
are all immutable and it's usefulness to concurrency. So I began to
wonder, what would an Immutable Ruby look like?

* Would it make setter methods effectively pointless?

The notion of a setter is probably very problematic.

* Overall, would it help or hurt efficiency/speed?

Depends on a single processor slower, on a high concurrency N core processor, faster.

* Would it ruin Ruby's elegance?

Yes, no. It becomes conceptually cleaner. The garbage collection becomes cleaner and easier.

I suspect it will force you to think to really really think about
which class owns which other class.

* No more #<< :frowning:

Nor any ! method.

* Is such a thing even possible?

Sort like Star Trek... "It's life Jim, but not as we know it"

To find out what it would be like replace every
   Blah.new(arg1,arg2...)
    with
   Blah.new(arg1,arg2...).freeze

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

···

On Fri, 29 Aug 2008, Trans wrote:

2

John Carter wrote:

To find out what it would be like replace every
  Blah.new(arg1,arg2...)
   with
  Blah.new(arg1,arg2...).freeze

$".freeze
require "fileutils"

Life is not good. Beam me up Scotty.

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

3

Almost. From my understanding Immutable objects can have internal
changing state as long as it is never exposed to the outside world.
For instance, memoize is a good example.

Am I right about that?

T.

···

On Aug 28, 10:07 pm, John Carter <john.car...@tait.co.nz> wrote:

To find out what it would be like replace every
Blah.new(arg1,arg2...)
with
Blah.new(arg1,arg2...).freeze