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:Paul King (
Date:Mar 2, 2009 4:11:32 am

All good ideas but we should think through this carefully. Java has some methods which mutate and others which create new objects. Ruby has sort and sort! conventions as an alternative scheme to better distinguish mutating methods.

I think we should put together some use cases and think through what immutable friendly versions of sort, plus, collect, etc. might look like (some of these apply only to collection like things). Then, even though we might not implement all the features, we could implement the cloneWith (or whatever we call it) feature in a way that allows expandability.

Or to think about it in a different way, Scala and Clojure and Haskell provide very nice features for handling immutability. Let's put together a few use cases and then consider what primitives we need to support them.


Guillaume Laforge wrote:

Or perhaps just with(Map), ie.

def c3 = c2.with latitude: 49.13123

That way we can add any properties we like.

The @Immutable transformation would check a with() method exists or not. If it exists, we do nothing, if it doesn't, we add that with(Map) method.

Perhaps the name should be cloneWith(Map) ?

On Mon, Mar 2, 2009 at 12:56, melix <> wrote:

I like the idea. However, I think the "modify" syntax could be replaced with a fluent-like API ("with" seems to be commonly used for immutables, I can remember of Joda Time using this syntax) :

def c3 = c2.withLatitude 49.13123

glaforge wrote:

There's a comment on my InfoQ article on Groovy 1.6 about @Immutable:

Some interesting thoughts:

*Great to see that the groovy team is embracing immutability as a critical part of the language.

Can methods require @immutable arguments and return types? That would make it possible to write side effect free functions that can be parallelized. If the compiler can enforce immutability, then it would be trivial to write an erlang-like messaging library or a a parallelized linear algebra implementation.

Also, immutable types should also generate modifiers for all properties. Otherwise, working with immutable types is cumbersome and involves a lot of boilerplate copying of fields between objects.

Example: def c1 = new Coordinates(latitude: 48.824068, longitude: 2.531733) def c2 = new Coordinates(48.824068, 2.531733

//copies the prior longitude, and sets the latitude to the provided value def c3 = c2.modify(latitude:49.13123)

This is a trivial example, but in practice data structures can be large and complicated, so it should be trivial to create slight variations of existing data.

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. *

Perhaps some of these suggestions would be nice to have? What do you think?