“final” and read only properties.

[Luke Daley]

Hi all,

There was recently a thread discussing the “final” modifier. It  
mentioned that someday it is hoped that this shares the semantics of  
“final” in Java.

I tend to use “final” to generate read only properties quite a lot and  
don't use it for the semantics of “final” in Java.

If this is going to be changed, a new forward compatible mechanism for  
read only properties should be introduced _soon_.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

I'd vote against "final" locking down variables in Groovy in general.  That's a kind of type safety
that I don't think would offer much to Groovy code: what would we really gain?

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Luke Daley wrote:

> Hi all,
>
> There was recently a thread discussing the “final” modifier. It
> mentioned that someday it is hoped that this shares the semantics of
> “final” in Java.
>
> I tend to use “final” to generate read only properties quite a lot and
> don't use it for the semantics of “final” in Java.
>
> If this is going to be changed, a new forward compatible mechanism for
> read only properties should be introduced
> _soon_.---------------------------------------------------------------------
>
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

Robert Fischer wrote:
> I'd vote against "final" locking down variables in Groovy in general.  
> That's a kind of type safety that I don't think would offer much to
> Groovy code: what would we really gain?

It doesn't really have a cost, because if you don't like it, you don't
have to use it.  And for people trying to track down a "why did this
change?" kind of bug, it can help.

I think "final" already works for fields, just not for local variables
or method parameters.  I'm not sure about properties though.

Best,
Martin

>
> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Grails Expert Retainer Services
> http://smokejumperit.com/grails-retainer/
>
>
> Luke Daley wrote:
>> Hi all,
>>
>> There was recently a thread discussing the “final” modifier. It
>> mentioned that someday it is hoped that this shares the semantics of
>> “final” in Java.
>>
>> I tend to use “final” to generate read only properties quite a lot and
>> don't use it for the semantics of “final” in Java.
>>
>> If this is going to be changed, a new forward compatible mechanism for
>> read only properties should be introduced
>> _soon_.---------------------------------------------------------------------
>>
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Wed, 2009-10-28 at 21:57 -0400, Robert Fischer wrote:
> I'd vote against "final" locking down variables in Groovy in general.  That's a kind of type safety
> that I don't think would offer much to Groovy code: what would we really gain?

I'd vote for the opposite.  I think single-assignment approaches are
worth following even in a dynamic language.  It isn't a type safety
issue, it is a reference binding/naming issue.

OK so Java 5.0 reflection can subvert it, but that isn't an argument for
throwing the baby out with the bathwater -- at least not for me.

> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Grails Expert Retainer Services
> http://smokejumperit.com/grails-retainer/
>
>
> Luke Daley wrote:
> > Hi all,
> >
> > There was recently a thread discussing the “final” modifier. It
> > mentioned that someday it is hoped that this shares the semantics of
> > “final” in Java.
> >
> > I tend to use “final” to generate read only properties quite a lot and
> > don't use it for the semantics of “final” in Java.
> >
> > If this is going to be changed, a new forward compatible mechanism for
> > read only properties should be introduced
> > _soon_.---------------------------------------------------------------------

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Steve Buroff]

I would like to see groovy as consistent with Java as possible. Therefore, I
would like "final" defined as it is in java. However, I also think
"read-only" is very useful so I'd like to see it implemented but with another
mechanism.

Steve

> -----Original Message-----
> From: Martin C. Martin [mailto:martin@...]
> Sent: Thursday, October 29, 2009 6:22 AM
> To: dev@...
> Subject: Re: [groovy-dev] “final” and read only properties.
>
> Robert Fischer wrote:
> > I'd vote against "final" locking down variables in Groovy in general.
> > That's a kind of type safety that I don't think would offer much to
> > Groovy code: what would we really gain?
>
> It doesn't really have a cost, because if you don't like it, you don't
> have to use it.  And for people trying to track down a "why did this
> change?" kind of bug, it can help.
>
> I think "final" already works for fields, just not for local variables
> or method parameters.  I'm not sure about properties though.
>
> Best,
> Martin
>
> >
> > ~~ Robert Fischer, Smokejumper IT Consulting.
> > Enfranchised Mind Blog http://EnfranchisedMind.com/blog
> >
> > Grails Expert Retainer Services
> > http://smokejumperit.com/grails-retainer/
> >
> >
> > Luke Daley wrote:
> >> Hi all,
> >>
> >> There was recently a thread discussing the “final” modifier. It
> >> mentioned that someday it is hoped that this shares the semantics of
> >> “final” in Java.
> >>
> >> I tend to use “final” to generate read only properties quite a lot
> and
> >> don't use it for the semantics of “final” in Java.
> >>
> >> If this is going to be changed, a new forward compatible mechanism
> for
> >> read only properties should be introduced
> >> _soon_.-------------------------------------------------------------
> --------
> >>
> >> To unsubscribe from this list, please visit:
> >>
> >>    http://xircles.codehaus.org/manage_email
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

In Java, a single-assignment violation is caught by the compiler, which is the only reason the
stricter "final" is valuable.  Unless I'm mistaken, Groovy wouldn't have this capability.

Given that, we're only talking about runtime semantics:
class Foo {
   final bar
}
new Foo().bar = "bar"  // throws ReadOnlyPropertyException

In this case, we'd have pretty much the same runtime semantics if the field was read-only at the
bytecode level, too (perhaps with a less nice exception).

The semantic here is a bit different:
class Foo {
   final bar
}
new Foo().@bar = "bar"  // works

And I'm not opposed to that exploding.  Likely should.  And if someone was reaching in and mangling
the fields of a collaborator class directly, I have no qualms punishing them by hooking their code up.

The major difference, though, is in stunts like this:
class Foo {
   final bar
   def mangleBar() { bar = "bar" }
}
new Foo().mangleBar()  // works

Which basically gets us back to how much we trust the people writing the class's internals.  Groovy
gives a lot of trust and freedom to that person.

If this wasn't a breaking change, I'd be for it.  But I don't see enough value in the breaking
change to warrant the rather significant break.  I know I've got code in the field that leverages
"final" as meaning "nobody outside of this class should touch this variable", which would all have
to get changed.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Russel Winder wrote:

> On Wed, 2009-10-28 at 21:57 -0400, Robert Fischer wrote:
>> I'd vote against "final" locking down variables in Groovy in general.  That's a kind of type safety
>> that I don't think would offer much to Groovy code: what would we really gain?
>
> I'd vote for the opposite.  I think single-assignment approaches are
> worth following even in a dynamic language.  It isn't a type safety
> issue, it is a reference binding/naming issue.
>
> OK so Java 5.0 reflection can subvert it, but that isn't an argument for
> throwing the baby out with the bathwater -- at least not for me.
>
>> ~~ Robert Fischer, Smokejumper IT Consulting.
>> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>>
>> Grails Expert Retainer Services
>> http://smokejumperit.com/grails-retainer/
>>
>>
>> Luke Daley wrote:
>>> Hi all,
>>>
>>> There was recently a thread discussing the “final” modifier. It
>>> mentioned that someday it is hoped that this shares the semantics of
>>> “final” in Java.
>>>
>>> I tend to use “final” to generate read only properties quite a lot and
>>> don't use it for the semantics of “final” in Java.
>>>
>>> If this is going to be changed, a new forward compatible mechanism for
>>> read only properties should be introduced
>>> _soon_.---------------------------------------------------------------------
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Luke Daley schrieb:

> Hi all,
>
> There was recently a thread discussing the “final” modifier. It
> mentioned that someday it is hoped that this shares the semantics of
> “final” in Java.
>
> I tend to use “final” to generate read only properties quite a lot and
> don't use it for the semantics of “final” in Java.
>
> If this is going to be changed, a new forward compatible mechanism for
> read only properties should be introduced
> _soon_.

what final on a property should mean in groovy is
(1) no setter
(2) field is final
(3) setting the field from inside the class gives a compile time error

we currently have 1+2. The VM does not forbid setting a final field from
inside the class, so for 3 a compile time check is needed and that is
not done yet for various reasons. In the end it wouldn't be much work to
do that. Just a bit tweaking to VariableScopeVisitor.

If we go and do point 3 too, is that a change for you?

Oh I forgot (4) setting the property from outside the class. This is a
runtime check, that should be in already. And (5) setting the field from
outside the class. Here maybe a runtime check is missing.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Scott Davis-7]

If GPars, Groovy Actors, et al are going to be taken seriously, then  
"final" should mean "immutable" in the sense of 1-5 as blackdrag  
enumerated. Otherwise, what is the point?

(Note on my tone: not meant to be snarky or offensive or in any way  
flame-bait...)

If final != immutable in Groovy, then we need to be really, REALLY  
careful about talking about Groovy in the same context of Scala,  
Clojure, et al where immutability == immutability.

Cheers,
s


On Oct 29, 2009, at 8:42 AM, Jochen Theodorou wrote:

> Luke Daley schrieb:
>> Hi all,
>> There was recently a thread discussing the “final” modifier. It  
>> mentioned that someday it is hoped that this shares the semantics  
>> of “final” in Java.
>> I tend to use “final” to generate read only properties quite a lot  
>> and don't use it for the semantics of “final” in Java.
>> If this is going to be changed, a new forward compatible mechanism  
>> for read only properties should be introduced _soon_.
>
>
> what final on a property should mean in groovy is
> (1) no setter
> (2) field is final
> (3) setting the field from inside the class gives a compile time error
>
> we currently have 1+2. The VM does not forbid setting a final field  
> from inside the class, so for 3 a compile time check is needed and  
> that is not done yet for various reasons. In the end it wouldn't be  
> much work to do that. Just a bit tweaking to VariableScopeVisitor.
>
> If we go and do point 3 too, is that a change for you?
>
> Oh I forgot (4) setting the property from outside the class. This is  
> a runtime check, that should be in already. And (5) setting the  
> field from outside the class. Here maybe a runtime check is missing.
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Scott Davis schrieb:
> If GPars, Groovy Actors, et al are going to be taken seriously, then
> "final" should mean "immutable" in the sense of 1-5 as blackdrag
> enumerated. Otherwise, what is the point?

Apart from what people seem to think, the field is and has always been
final. It is just that you can change final fields of a class from
inside the class. The VM is not doing checks here. From outside the VM
wold do checks, but the MOP helper methods in the class bypass that.
Just because a command is executed to set the field does not mean the
field is really changed though. So it is very possible that for a final
field a=1; assert a=1 will fail.

> (Note on my tone: not meant to be snarky or offensive or in any way
> flame-bait...)

I did not interpret anything like that into your comment.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

On Thu, Oct 29, 2009 at 7:02 PM, Scott Davis <list@...> wrote:

> If GPars, Groovy Actors, et al are going to be taken seriously, then "final"
> should mean "immutable" in the sense of 1-5 as blackdrag enumerated.
> Otherwise, what is the point?
>
> (Note on my tone: not meant to be snarky or offensive or in any way
> flame-bait...)
>
> If final != immutable in Groovy, then we need to be really, REALLY careful
> about talking about Groovy in the same context of Scala, Clojure, et al
> where immutability == immutability.

final != immutability. You can declare a reference as final in Java
but that doesn't make it thread safe. They're two distinct concepts in
my view.

I agree there is a need for a language level construct to enforce
immutability, but final is not it

Cheers

>
> Cheers,
> s
>
>
> On Oct 29, 2009, at 8:42 AM, Jochen Theodorou wrote:
>
>> Luke Daley schrieb:
>>>
>>> Hi all,
>>> There was recently a thread discussing the “final” modifier. It mentioned
>>> that someday it is hoped that this shares the semantics of “final” in Java.
>>> I tend to use “final” to generate read only properties quite a lot and
>>> don't use it for the semantics of “final” in Java.
>>> If this is going to be changed, a new forward compatible mechanism for
>>> read only properties should be introduced _soon_.
>>
>>
>> what final on a property should mean in groovy is
>> (1) no setter
>> (2) field is final
>> (3) setting the field from inside the class gives a compile time error
>>
>> we currently have 1+2. The VM does not forbid setting a final field from
>> inside the class, so for 3 a compile time check is needed and that is not
>> done yet for various reasons. In the end it wouldn't be much work to do
>> that. Just a bit tweaking to VariableScopeVisitor.
>>
>> If we go and do point 3 too, is that a change for you?
>>
>> Oh I forgot (4) setting the property from outside the class. This is a
>> runtime check, that should be in already. And (5) setting the field from
>> outside the class. Here maybe a runtime check is missing.
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou
>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>> http://blackdragsview.blogspot.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>  http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Dierk König]

given that in languages like Groovy, runtime and compiletime is often  
intermixed,
pushing checks from runtime to compiletime is much less valuable.

I think we should develop a Groovy "checker" tool that people can use
before pre-compiling Groovy for production purposes that points out
calls that will lead to runtime errors. Such a tool can be much more  
rigid
than the compiler.

We may want to base it on codenarc.

cheers
Dierk


Am 29.10.2009 um 15:42 schrieb Jochen Theodorou:

> Luke Daley schrieb:
>> Hi all,
>> There was recently a thread discussing the “final” modifier. It  
>> mentioned that someday it is hoped that this shares the semantics  
>> of “final” in Java.
>> I tend to use “final” to generate read only properties quite a lot  
>> and don't use it for the semantics of “final” in Java.
>> If this is going to be changed, a new forward compatible mechanism  
>> for read only properties should be introduced _soon_.
>
>
> what final on a property should mean in groovy is
> (1) no setter
> (2) field is final
> (3) setting the field from inside the class gives a compile time error
>
> we currently have 1+2. The VM does not forbid setting a final field  
> from inside the class, so for 3 a compile time check is needed and  
> that is not done yet for various reasons. In the end it wouldn't be  
> much work to do that. Just a bit tweaking to VariableScopeVisitor.
>
> If we go and do point 3 too, is that a change for you?
>
> Oh I forgot (4) setting the property from outside the class. This is  
> a runtime check, that should be in already. And (5) setting the  
> field from outside the class. Here maybe a runtime check is missing.
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

Scala and (to a much greater extent) Clojure draw from a functional language heritage.  Groovy
doesn't.  It draws from the scripting language background.  The scripting language background has
picked up some functional syntactic shorthand, but otherwise the functional language paradigm is
foreign to Groovy.  If you don't believe me, go code Haskell or OCaml or F# for six months and then
see what you think.

Structures like actors and dataflow concurrency only require things to be "immutable enough".  E.G.:
In an actor system, you should not mutate when the object is being passed as a message, but it's
fine for a single thread to mutate the payload of a message (or even the message itself) and then
pass it on.  This statement is assuming actors don't retain references to messages once they are
sent, which is just one of a multitude of non-compiler-checked/non-runtime-checked assumptions which
the developer is responsible for doing right.  So given that we already have all these
responsibilities and already have a culture of minimal compiler interference, I'm not sold on the
value-add of compiler-enforced immutability, particularly as a breaking change to the language.

It's better to use the @Immutable AST transform, which even handles a number of broken corner cases
in the Java-final-gives-"immutability == immutability" assumption.

[BTW, in more complicated systems, I actually like using Groovy and Scala together, because I can
construct my immutable fiddly bits in Scala and then work with them in Groovy (whose flexible syntax
and metaprogramming is much nicer).  Y'know, someone should write a book on that kind of stuff...]

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Scott Davis wrote:

> If GPars, Groovy Actors, et al are going to be taken seriously, then
> "final" should mean "immutable" in the sense of 1-5 as blackdrag
> enumerated. Otherwise, what is the point?
>
> (Note on my tone: not meant to be snarky or offensive or in any way
> flame-bait...)
>
> If final != immutable in Groovy, then we need to be really, REALLY
> careful about talking about Groovy in the same context of Scala,
> Clojure, et al where immutability == immutability.
>
> Cheers,
> s
>
>
> On Oct 29, 2009, at 8:42 AM, Jochen Theodorou wrote:
>
>> Luke Daley schrieb:
>>> Hi all,
>>> There was recently a thread discussing the “final” modifier. It
>>> mentioned that someday it is hoped that this shares the semantics of
>>> “final” in Java.
>>> I tend to use “final” to generate read only properties quite a lot
>>> and don't use it for the semantics of “final” in Java.
>>> If this is going to be changed, a new forward compatible mechanism
>>> for read only properties should be introduced _soon_.
>>
>>
>> what final on a property should mean in groovy is
>> (1) no setter
>> (2) field is final
>> (3) setting the field from inside the class gives a compile time error
>>
>> we currently have 1+2. The VM does not forbid setting a final field
>> from inside the class, so for 3 a compile time check is needed and
>> that is not done yet for various reasons. In the end it wouldn't be
>> much work to do that. Just a bit tweaking to VariableScopeVisitor.
>>
>> If we go and do point 3 too, is that a change for you?
>>
>> Oh I forgot (4) setting the property from outside the class. This is a
>> runtime check, that should be in already. And (5) setting the field
>> from outside the class. Here maybe a runtime check is missing.
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou
>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>> http://blackdragsview.blogspot.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Robert Fischer schrieb:
> Scala and (to a much greater extent) Clojure draw from a functional
> language heritage.  Groovy doesn't.  It draws from the scripting
> language background.  The scripting language background has picked up
> some functional syntactic shorthand, but otherwise the functional
> language paradigm is foreign to Groovy.  If you don't believe me, go
> code Haskell or OCaml or F# for six months and then see what you think.

what is the functional language paradigm... I think you should name it
so all people reading know what you mean. I assume you mean being free
of side effects, but I leave the details to you ;)

> Structures like actors and dataflow concurrency only require things to
> be "immutable enough".  E.G.: In an actor system, you should not mutate
> when the object is being passed as a message, but it's fine for a single
> thread to mutate the payload of a message (or even the message itself)
> and then pass it on.  This statement is assuming actors don't retain
> references to messages once they are sent, which is just one of a
> multitude of non-compiler-checked/non-runtime-checked assumptions which
> the developer is responsible for doing right.  So given that we already
> have all these responsibilities and already have a culture of minimal
> compiler interference, I'm not sold on the value-add of
> compiler-enforced immutability, particularly as a breaking change to the
> language.

 >
> It's better to use the @Immutable AST transform, which even handles a
> number of broken corner cases in the Java-final-gives-"immutability ==
> immutability" assumption.

I agree here very much.

> [BTW, in more complicated systems, I actually like using Groovy and
> Scala together, because I can construct my immutable fiddly bits in
> Scala and then work with them in Groovy (whose flexible syntax and
> metaprogramming is much nicer).  Y'know, someone should write a book on
> that kind of stuff...]

well... do it? haha. What I have in my mind could open for Groovy an
optional functional path, but by nature Groovy would of course always be
a mix. Some functional concepts, some object oriented concepts, some
script concepts and even procedural patterns. Since it is a mix, a
functional programming evangelist will most probably not like it. If
functional people don't pay attention to Groovy, then it won't develop
in that direction, preventing more people from doing so.

bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

An exploration of the functional programming language paradigm by my co-blogger, Brian Hurt:
http://enfranchisedmind.com/blog/posts/what-is-a-functional-programming-language/

That post is a response to my post about Scala disillusionment:
http://enfranchisedmind.com/blog/posts/scala-not-functional/

I have no problem with Groovy playing with functional concepts.  I support it, in fact, because it's
always interesting to see what fits in well and what's a bit awkward.  For instance, another live
thread is discussing that #inject is a bit weird and touchy (I always forget to return the new
memo), but a hybrid between #inject and #each is really nice.  That's a cool little discovery, at
least by my reckoning.

I do have a problem with the argument that we should introduce breaking changes into Groovy in order
to match Java's bad pseudo-immutability semantics of "final".  And I have a really big problem with
the argument that Groovy needs to implement a breaking change to match the bad "final" because Scala
and Clojure have immutability structures.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Jochen Theodorou wrote:

> Robert Fischer schrieb:
>> Scala and (to a much greater extent) Clojure draw from a functional
>> language heritage.  Groovy doesn't.  It draws from the scripting
>> language background.  The scripting language background has picked up
>> some functional syntactic shorthand, but otherwise the functional
>> language paradigm is foreign to Groovy.  If you don't believe me, go
>> code Haskell or OCaml or F# for six months and then see what you think.
>
> what is the functional language paradigm... I think you should name it
> so all people reading know what you mean. I assume you mean being free
> of side effects, but I leave the details to you ;)
>
>> Structures like actors and dataflow concurrency only require things to
>> be "immutable enough".  E.G.: In an actor system, you should not
>> mutate when the object is being passed as a message, but it's fine for
>> a single thread to mutate the payload of a message (or even the
>> message itself) and then pass it on.  This statement is assuming
>> actors don't retain references to messages once they are sent, which
>> is just one of a multitude of non-compiler-checked/non-runtime-checked
>> assumptions which the developer is responsible for doing right.  So
>> given that we already have all these responsibilities and already have
>> a culture of minimal compiler interference, I'm not sold on the
>> value-add of compiler-enforced immutability, particularly as a
>> breaking change to the language.
>  >
>> It's better to use the @Immutable AST transform, which even handles a
>> number of broken corner cases in the Java-final-gives-"immutability ==
>> immutability" assumption.
>
> I agree here very much.
>
>> [BTW, in more complicated systems, I actually like using Groovy and
>> Scala together, because I can construct my immutable fiddly bits in
>> Scala and then work with them in Groovy (whose flexible syntax and
>> metaprogramming is much nicer).  Y'know, someone should write a book
>> on that kind of stuff...]
>
> well... do it? haha. What I have in my mind could open for Groovy an
> optional functional path, but by nature Groovy would of course always be
> a mix. Some functional concepts, some object oriented concepts, some
> script concepts and even procedural patterns. Since it is a mix, a
> functional programming evangelist will most probably not like it. If
> functional people don't pay attention to Groovy, then it won't develop
> in that direction, preventing more people from doing so.
>
> bye blackdrag

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Robert Fischer schrieb:
[...]
> I do have a problem with the argument that we should introduce breaking
> changes into Groovy in order to match Java's bad pseudo-immutability
> semantics of "final".  And I have a really big problem with the argument
> that Groovy needs to implement a breaking change to match the bad
> "final" because Scala and Clojure have immutability structures.

ok, let us concentrate on Groovy. What would be the breaking change?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

The break would be in code like this:
class Foo {
   final bar
   def mangleBar() { bar = "bar!" }
}
new Foo().mangleBar()

Right now, "final" communicates "not modifiable by the outside world".  The proposal is to change
that to mean "not modifiable by anyone (even the inside world) after the constructor".  That's a
breaking change, in that it breaks all code using the existing "final" semantics, which is a very
useful semantic (even if surprising to Java developers).

BTW, the outside world *could* touch the field directly (see below), but if you're touching fields
to get around read-only properties, you're making your own bed.

class Foo {
   final bar
}
def f = new Foo()
f.@bar = "bar"
println f.bar

Also BTW, if we do decide to break a bunch of code in order to make "final" more strict, how about
we go the whole 9 yards and make "final" mean "@Immutable"?  At least that would avoid *some* of the
final-means-immutable-but-not-really issues.  Java's broken "final" has always irked me a bit, even
though I love it dearly.  Ultimately, immutable always means immutable-but-not-really in a Java
derivative language unless you stick to the fields holding only native types, immutable objects, and
collections which hold immutable objects and aren't shared with the outside world except via
immutable wrappers.  Given that the metaClass property hangs off every GroovyObject, and it's none
of those, we'll never have true immutability...but that's probably getting overly pedantic.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Jochen Theodorou wrote:

> Robert Fischer schrieb:
> [...]
>> I do have a problem with the argument that we should introduce
>> breaking changes into Groovy in order to match Java's bad
>> pseudo-immutability semantics of "final".  And I have a really big
>> problem with the argument that Groovy needs to implement a breaking
>> change to match the bad "final" because Scala and Clojure have
>> immutability structures.
>
> ok, let us concentrate on Groovy. What would be the breaking change?
>
> bye blackdrag
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Luke Daley]

The most sensible thing to do for my money is to have “final” be as  
close to Java semantics as possible in Groovy 2. DON'T try and add  
additional meaning because while interesting academically it will only  
confuse. Introduce a new machanism for setter only generation SOON and  
start communicating the change.

On 30/10/2009, at 11:30 AM, Robert Fischer <robert.fischer@...
 > wrote:

> The break would be in code like this:
> class Foo {
>  final bar
>  def mangleBar() { bar = "bar!" }
> }
> new Foo().mangleBar()
>
> Right now, "final" communicates "not modifiable by the outside  
> world".  The proposal is to change that to mean "not modifiable by  
> anyone (even the inside world) after the constructor".  That's a  
> breaking change, in that it breaks all code using the existing  
> "final" semantics, which is a very useful semantic (even if  
> surprising to Java developers).
>
> BTW, the outside world *could* touch the field directly (see below),  
> but if you're touching fields to get around read-only properties,  
> you're making your own bed.
>
> class Foo {
>  final bar
> }
> def f = new Foo()
> f.@bar = "bar"
> println f.bar
>
> Also BTW, if we do decide to break a bunch of code in order to make  
> "final" more strict, how about we go the whole 9 yards and make  
> "final" mean "@Immutable"?  At least that would avoid *some* of the  
> final-means-immutable-but-not-really issues.  Java's broken "final"  
> has always irked me a bit, even though I love it dearly.  
> Ultimately, immutable always means immutable-but-not-really in a  
> Java derivative language unless you stick to the fields holding only  
> native types, immutable objects, and collections which hold  
> immutable objects and aren't shared with the outside world except  
> via immutable wrappers.  Given that the metaClass property hangs off  
> every GroovyObject, and it's none of those, we'll never have true  
> immutability...but that's probably getting overly pedantic.
>
> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Grails Expert Retainer Services
> http://smokejumperit.com/grails-retainer/
>
>
> Jochen Theodorou wrote:
>> Robert Fischer schrieb:
>> [...]
>>> I do have a problem with the argument that we should introduce  
>>> breaking changes into Groovy in order to match Java's bad pseudo-
>>> immutability semantics of "final".  And I have a really big  
>>> problem with the argument that Groovy needs to implement a  
>>> breaking change to match the bad "final" because Scala and Clojure  
>>> have immutability structures.
>> ok, let us concentrate on Groovy. What would be the breaking change?
>> bye blackdrag
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Robert Fischer schrieb:

> The break would be in code like this:
> class Foo {
>   final bar
>   def mangleBar() { bar = "bar!" }
> }
> new Foo().mangleBar()
>
> Right now, "final" communicates "not modifiable by the outside world".  
> The proposal is to change that to mean "not modifiable by anyone (even
> the inside world) after the constructor".  That's a breaking change, in
> that it breaks all code using the existing "final" semantics, which is a
> very useful semantic (even if surprising to Java developers).

the part I am worried about is the java memory model. It guarantees an
initialized value for the field without synchronization. But if I change
that value, then I may do that with an unitialized one, meaning the
guarantee is no longer of value. If someone else now thinks in Java
terms, then this is unexpected.

[...]

> Also BTW, if we do decide to break a bunch of code in order to make
> "final" more strict, how about we go the whole 9 yards and make "final"
> mean "@Immutable"?  At least that would avoid *some* of the
> final-means-immutable-but-not-really issues.  Java's broken "final" has
> always irked me a bit, even though I love it dearly.  Ultimately,
> immutable always means immutable-but-not-really in a Java derivative
> language unless you stick to the fields holding only native types,
> immutable objects, and collections which hold immutable objects and
> aren't shared with the outside world except via immutable wrappers.  
> Given that the metaClass property hangs off every GroovyObject, and it's
> none of those, we'll never have true immutability...but that's probably
> getting overly pedantic.

you mean final should not mean an immutable reference value, but a truly
immutable object? If there were an easy way to know an object that is
assigned to that field is immutable I would agree right away. But...
doing all that stuff at compile time means the field we make final would
have to be a final class or primitive and a class we recognize as
immutable by either it had been declared with @Immutable or a known
case. Currently @Immutable is only a helper and documentation. You can
use it or not, that is up to you.

Maybe.. if we think in that direction, then maybe we should start out
with a normal annotation to not to restrict ourselfs and then decide if
it fits enough with final to make a replacement or if it should stay
that way. What do you think?

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

Erk.  The memory model argument is a good point.  That could suck for concurrency situations.
Especially with gpars.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Jochen Theodorou wrote:

> Robert Fischer schrieb:
>> The break would be in code like this:
>> class Foo {
>>   final bar
>>   def mangleBar() { bar = "bar!" }
>> }
>> new Foo().mangleBar()
>>
>> Right now, "final" communicates "not modifiable by the outside
>> world".  The proposal is to change that to mean "not modifiable by
>> anyone (even the inside world) after the constructor".  That's a
>> breaking change, in that it breaks all code using the existing "final"
>> semantics, which is a very useful semantic (even if surprising to Java
>> developers).
>
> the part I am worried about is the java memory model. It guarantees an
> initialized value for the field without synchronization. But if I change
> that value, then I may do that with an unitialized one, meaning the
> guarantee is no longer of value. If someone else now thinks in Java
> terms, then this is unexpected.
>
> [...]
>> Also BTW, if we do decide to break a bunch of code in order to make
>> "final" more strict, how about we go the whole 9 yards and make
>> "final" mean "@Immutable"?  At least that would avoid *some* of the
>> final-means-immutable-but-not-really issues.  Java's broken "final"
>> has always irked me a bit, even though I love it dearly.  Ultimately,
>> immutable always means immutable-but-not-really in a Java derivative
>> language unless you stick to the fields holding only native types,
>> immutable objects, and collections which hold immutable objects and
>> aren't shared with the outside world except via immutable wrappers.  
>> Given that the metaClass property hangs off every GroovyObject, and
>> it's none of those, we'll never have true immutability...but that's
>> probably getting overly pedantic.
>
> you mean final should not mean an immutable reference value, but a truly
> immutable object? If there were an easy way to know an object that is
> assigned to that field is immutable I would agree right away. But...
> doing all that stuff at compile time means the field we make final would
> have to be a final class or primitive and a class we recognize as
> immutable by either it had been declared with @Immutable or a known
> case. Currently @Immutable is only a helper and documentation. You can
> use it or not, that is up to you.
>
> Maybe.. if we think in that direction, then maybe we should start out
> with a normal annotation to not to restrict ourselfs and then decide if
> it fits enough with final to make a replacement or if it should stay
> that way. What do you think?
>
> bye blackdrag
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

Jochen,

On Thu, 2009-10-29 at 23:58 +0100, Jochen Theodorou wrote:
[ . . . ]
> what is the functional language paradigm... I think you should name it
> so all people reading know what you mean. I assume you mean being free
> of side effects, but I leave the details to you ;)
[ . . . ]

Forgive me but this is just being argumentative.  If people working in
programming do not understand correctly what the terms
"object-oriented", "functional", "declarative", "imperative",
"procedural", "logic", "constraint-based" mean as relates to
computational models and programming languages, then they need to go
back to school.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder