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:53:51 am
List:org.codehaus.groovy.dev

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

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

yes, true. But what I do not like here so much is the sequence dependency of the params (it does not work if you put latitude:4 in the front of the parameter
list).

That's why I've put the latitude in second.

I'm not even sure that the sequence handling is a guaranteed behaviour.

I haven't double checked how we're handling that in the code, but I think it's guaranteed.

Second, there may be problems with properties like "metaClass" ;-)

Although I don't see any special treatment for that case in the code of @Immutable, it seems that if I change the metaClass of the first coord, then call the constructor of the second coord that way, the MetaClass is not copied, so it's the normal MetaClass that is used. Which is okay to me. What would you think the behaviour should be? Perhaps we may have to do some special handling here.

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?

You can modify any object at your will. After calling obj.freeze(), any further attempt to modify it, throws an Error.

Okie dokie, I see.