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:Martin C. Martin (mar@martincmartin.com)
Date:Mar 2, 2009 5:31:40 am
List:org.codehaus.groovy.dev

Can methods require @immutable arguments and return types? That would make it possible to write side effect free functions that can be parallelized.

Actually, that doesn't follow since the function can modify static class members or call functions on them. So the compiler would have to enforce that it doesn't call any side effecting functions or modify any global state. And the runtime would have to ensure this as well, since pretty much any function or operator can be replaced at runtime, even in another thread.

Support for immutable types is critical as more people attempt to embrace multi-core machines through message based concurrency or side-effect free functional programming.

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?

Best, Martin