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:Guillaume Laforge (glaf@codehaus.org)
Date:Mar 2, 2009 3:01:26 am
List:org.codehaus.groovy.dev

On Mon, Mar 2, 2009 at 11:38, Dierk König <dier@canoo.com> wrote:

I like the "modifier" approach. The downside is that we need to reserve a name for this (namely "modify").

Right, that's a downside.

An alternative would be to provide a copy-constructor that takes a map of modified properties and a prototype.

def c3 = new Coordinates(latitude: 12.3456 , c2 )

I could use this instantly for my current project ;-)

There's already a "groovy way" of doing this somehow, with a one liner:

@Immutable final class Coord { Double latitude, longitude }

def c1 = new Coord(1, 2)

assert c1.latitude == 1 assert c1.longitude == 2

def c2 = new Coord([*:c1.properties, latitude: 4])

assert c2.latitude == 4 assert c2.longitude == 2

BTW: Another suggestions that was raised at the JavaPosse newscast is to provide something similar to the Ruby freeze() method - mainly to allow bi-directional references between immutable objects. But this only works at runtime (not compile-time) and you will not get any IDE-warnings that way.

I'm not sure I understand what this freeze() method is doing. Could you please elaborate a bit?

Guillaume

cheers Dierk

Am 02.03.2009 um 11:16 schrieb Guillaume Laforge:

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

http://www.infoq.com/articles/groovy-1-6#view_39652

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?