atom feed23 messages in org.codehaus.groovy.devRe: [groovy-dev] Suggestions for @Imm...
FromSent OnAttachments
Guillaume LaforgeMar 2, 2009 2:16 am 
Dierk KönigMar 2, 2009 2:38 am 
Guillaume LaforgeMar 2, 2009 3:01 am 
Dierk KönigMar 2, 2009 3:40 am 
Guillaume LaforgeMar 2, 2009 3:53 am 
melixMar 2, 2009 3:56 am 
Guillaume LaforgeMar 2, 2009 3:59 am 
Paul KingMar 2, 2009 4:11 am 
Guillaume LaforgeMar 2, 2009 4:23 am 
Tom NicholsMar 2, 2009 4:39 am 
Michael MellingerMar 2, 2009 5:11 am 
Martin C. MartinMar 2, 2009 5:31 am 
Tom NicholsMar 2, 2009 6:19 am 
Robert FischerMar 2, 2009 6:25 am 
Robert FischerMar 2, 2009 6:39 am 
Tom NicholsMar 2, 2009 6:51 am 
Graeme RocherMar 2, 2009 6:56 am 
Alex TkachmanMar 2, 2009 7:07 am 
Robert FischerMar 2, 2009 7:08 am 
Robert FischerMar 2, 2009 7:13 am 
Alex TkachmanMar 2, 2009 8:18 am 
Robert FischerMar 2, 2009 8:58 am 
Guillaume LaforgeMar 3, 2009 1:39 am 
Subject:Re: [groovy-dev] Suggestions for @Immutable
From:Robert Fischer (robe@smokejumperit.com)
Date:Mar 2, 2009 6:39:10 am
List:org.codehaus.groovy.dev

See a tutorial here to take the magical veneer off of Actors: http://www.scala-lang.org/node/242

There's no reason you need language changes -- including @Immutable -- to
implement actors. It's a pretty simple design pattern which could be just as well implemented in Groovy.
We could even get the same syntax modulo "case ... =>" becoming "case ...: ... break".

Were I to design the library for Groovy, though, I wouldn't try to mimic Scala's
API: I'd probably implement actors with a more conventional approach: actOn(SomeType var) becomes
the handler for SomeType instances, with a "setUp", "teardown", "before", and "after" phase.
Bonus points for a conventional handle(Exception) methods (handle(IOException),
handle(RuntimeException), handle(Exception)).

Between my 9 to 5'er, my graduate school, GroovyMag training, Autobase, and
Cornerstone, I really don't have time to write up that code. But as someone who is big into
concurrency, functional programming, and language/library design, I'd be willing to provide
thoughts/guidance/critiques.

~~ Robert Fischer. Grails Training http://GroovyMag.com/training Smokejumper Consulting http://SmokejumperIT.com Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"! http://www.smokejumperit.com/redirect.html

Tom Nichols wrote:

On Mon, Mar 2, 2009 at 8:31 AM, Martin C. Martin <mar@martincmartin.com> wrote:

Groovy's approach to performance has generally been to never leave out or modify a feature strictly for performance, and when you need performance, you should rewrite the bottleneck in Java. When the world was single core, immutability was just a nice invariant, another check the compiler could do to catch certain kinds of errors. And it wasn't part of Java, let alone Groovy. (Java has "final" for variables and fields, but no notion that an entire object is immutable.)

So, unless I'm missing something, this seems like a feature that's difficult (or impossible?) to implement efficiently in the face of arbitrary metaclass changes at runtime. And it seems the main motivation is performance.

Or have I got it wrong?

The motivation, I believe is to actually not have to worry about multiple threads modifying shared memory. If objects are immutable you don't need to worry about somebody else changing that same instance. So it is not so much about performance, but readability and ease of designing concurrent systems. Java (an C variants) are notoriously difficult to write concurrent systems in. So "dropping down to Java" is not really helping in this case.

Scala seems to have achieved this fairly well with Actors and immutable types (which is built on the JVM). My impression had been that Scala would generally be more suitable for concurrent programming because of its compile-time checking. But I still have trouble with some of Scala's syntax and idioms, so if this model can in fact be applied successfully to Groovy I am all for it.