making arbitrary Object "reasonably immutable"

[Alex Tkachman]

Hi!

I want to suggest some way of making arbitrary object "reasonably
immutable" - see definition below.
The exact definition of "reasonable immutablity" is following - the
object called reasonably immutable if
- call to any setter method throws exception
- any return value of methods and property getters are also
"reasonably" immutable.

Main good thing about this is that it is not too complicated to
implement. DelegatingMetaClass is strong enough tool to protect
everything done in Groovy (except changing of metaclass). The main
problem is that we are not able to protect methods written in Java,
which change internal state of the Object.

 I would like to hear your opinions if it is really "reasonable" or
makes any sense at all?

Alex

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Alex Tkachman schrieb:

> Hi!
>
> I want to suggest some way of making arbitrary object "reasonably
> immutable" - see definition below.
> The exact definition of "reasonable immutablity" is following - the
> object called reasonably immutable if
> - call to any setter method throws exception
> - any return value of methods and property getters are also
> "reasonably" immutable.
>
> Main good thing about this is that it is not too complicated to
> implement. DelegatingMetaClass is strong enough tool to protect
> everything done in Groovy (except changing of metaclass). The main
> problem is that we are not able to protect methods written in Java,
> which change internal state of the Object.
>
>  I would like to hear your opinions if it is really "reasonable" or
> makes any sense at all?

why not using normal immutables?

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

[Alex Tkachman]

Yo means one annotated @Immutable?
It is OK in case of application (just require some discipline) but not
convinient in case of framework like GPars, which should protect
developer from shared-state mistake. It is pretty much my main example

On Fri, Oct 23, 2009 at 2:30 PM, Jochen Theodorou <blackdrag@...> wrote:

> Alex Tkachman schrieb:
>>
>> Hi!
>>
>> I want to suggest some way of making arbitrary object "reasonably
>> immutable" - see definition below.
>> The exact definition of "reasonable immutablity" is following - the
>> object called reasonably immutable if
>> - call to any setter method throws exception
>> - any return value of methods and property getters are also
>> "reasonably" immutable.
>>
>> Main good thing about this is that it is not too complicated to
>> implement. DelegatingMetaClass is strong enough tool to protect
>> everything done in Groovy (except changing of metaclass). The main
>> problem is that we are not able to protect methods written in Java,
>> which change internal state of the Object.
>>
>>  I would like to hear your opinions if it is really "reasonable" or
>> makes any sense at all?
>
> why not using normal immutables?
>
> 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]

Alex Tkachman schrieb:
> Yo means one annotated @Immutable?

that or by hand, yes.

> It is OK in case of application (just require some discipline) but not
> convinient in case of framework like GPars, which should protect
> developer from shared-state mistake. It is pretty much my main example

so what you really want to do is to protect an object against state
changes by using the meta class. Ok, but what about state changes that
are not done though a setter? To me it looks like you miss your target a
bit with that. Especially you have no easy way to know if the state is
shared. And even a getter could change the state.

The intention is surely right, but the tool does not look too right to
me. At maximum it could help a little - you could name it for example
"setter immutable". But this surely looks half baken to me as a solution.

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

[Wilson MacGyver]

While I too want better immutability support. I'm not sure it can
be done easily in groovy without introducing new keywords like scala's
val.

I don't think it's possible to achieve clojure's level of immutability support
in groovy.

On Fri, Oct 23, 2009 at 1:06 PM, Jochen Theodorou <blackdrag@...> wrote:

> Alex Tkachman schrieb:
>>
>> Yo means one annotated @Immutable?
>
> that or by hand, yes.
>
>> It is OK in case of application (just require some discipline) but not
>> convinient in case of framework like GPars, which should protect
>> developer from shared-state mistake. It is pretty much my main example
>
> so what you really want to do is to protect an object against state changes
> by using the meta class. Ok, but what about state changes that are not done
> though a setter? To me it looks like you miss your target a bit with that.
> Especially you have no easy way to know if the state is shared. And even a
> getter could change the state.
>
> The intention is surely right, but the tool does not look too right to me.
> At maximum it could help a little - you could name it for example "setter
> immutable". But this surely looks half baken to me as a solution.
>
> 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
>
>
>

--
Omnem crede diem tibi diluxisse supremum.

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Wilson MacGyver schrieb:
> While I too want better immutability support. I'm not sure it can
> be done easily in groovy without introducing new keywords like scala's
> val.
>
> I don't think it's possible to achieve clojure's level of immutability support
> in groovy.

of course it would be possible to achieve that but it would require
changes. For example I would add a transform, that checks the code for
being free of side effects. All side effect free parts can be executed
and rolled back. If during execution you meet a part with side effect
you have to react accordingly by synchronization or with for example an
exception. I would use annotations as marker for methods that are itself
side effect free and any java code would by default be not side effect
free. Then of course you cannot use normal lists and maps anymore,
unless they remain unchanged, which I would ensure through a special
class... and on and on. This model is quite different from the normal
execution model we have in Groovy, but it can be done, and it can be
done looking mostly native. I just don't have the time to realize
something like that.

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

[Wilson MacGyver]

real time check of a block code to ensure it's side effect free? that sounds
non-trivial. Also, the model you are describing, sounds like major breaking
change.

On Fri, Oct 23, 2009 at 1:26 PM, Jochen Theodorou <blackdrag@...> wrote:

> of course it would be possible to achieve that but it would require changes.
> For example I would add a transform, that checks the code for being free of
> side effects. All side effect free parts can be executed and rolled back. If
> during execution you meet a part with side effect you have to react
> accordingly by synchronization or with for example an exception. I would use
> annotations as marker for methods that are itself side effect free and any
> java code would by default be not side effect free. Then of course you
> cannot use normal lists and maps anymore, unless they remain unchanged,
> which I would ensure through a special class... and on and on. This model is
> quite different from the normal execution model we have in Groovy, but it
> can be done, and it can be done looking mostly native. I just don't have the
> time to realize something like that.
>
> 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
>
>
>

--
Omnem crede diem tibi diluxisse supremum.

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

    http://xircles.codehaus.org/manage_email

[Alex Tkachman]

Just for record - I don't propose any breaking change in Groovy.
I suggest some model for dynamic checking for immutability (on top of
Groovy Core) and interested in opinions of people who knows well
internal details of groovy runtime

On Fri, Oct 23, 2009 at 8:58 PM, Wilson MacGyver <wmacgyver@...> wrote:

> real time check of a block code to ensure it's side effect free? that sounds
> non-trivial. Also, the model you are describing, sounds like major breaking
> change.
>
> On Fri, Oct 23, 2009 at 1:26 PM, Jochen Theodorou <blackdrag@...> wrote:
>> of course it would be possible to achieve that but it would require changes.
>> For example I would add a transform, that checks the code for being free of
>> side effects. All side effect free parts can be executed and rolled back. If
>> during execution you meet a part with side effect you have to react
>> accordingly by synchronization or with for example an exception. I would use
>> annotations as marker for methods that are itself side effect free and any
>> java code would by default be not side effect free. Then of course you
>> cannot use normal lists and maps anymore, unless they remain unchanged,
>> which I would ensure through a special class... and on and on. This model is
>> quite different from the normal execution model we have in Groovy, but it
>> can be done, and it can be done looking mostly native. I just don't have the
>> time to realize something like that.
>>
>> 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
>>
>>
>>
>
>
>
> --
> Omnem crede diem tibi diluxisse supremum.
>
> ---------------------------------------------------------------------
> 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

[HamletDRC]

>> real time check of a block code to ensure it's side effect free? that sounds
>> non-trivial.

Has anyone read the "Verifiable functional purity in java" paper on
ACM? http://portal.acm.org/citation.cfm?id=1455770.1455793

If my memory serves correctly, the authors defined an annotation like
@SideEffectFree and then the compiler enforced that only other side
effect free functions could be called within a section maked @Pure.
(or something akin to that). Then provided a map file stating what
parts of the JDK (and other libraries) are side effect free.

It sounds like you want something similar: you want to enforce a type
system attribute (immutability) within a graph of objects. But you
want to do it at runtime instead of compile time.

Doesn't the dynamic nature of Groovy render this task impossible? Can
you really trace all dependencies of a class (both field and method
invocations) to make sure only other @Immutable entities are
referenced? As stated before, the setX notation of the bean spec is a
convention not a contract.

Perhaps I am over-thinking...

--
Hamlet D'Arcy
hamletdrc@...



On Fri, Oct 23, 2009 at 2:15 PM, Alex Tkachman <alex.tkachman@...> wrote:

> Just for record - I don't propose any breaking change in Groovy.
> I suggest some model for dynamic checking for immutability (on top of
> Groovy Core) and interested in opinions of people who knows well
> internal details of groovy runtime
>
> On Fri, Oct 23, 2009 at 8:58 PM, Wilson MacGyver <wmacgyver@...> wrote:
>> real time check of a block code to ensure it's side effect free? that sounds
>> non-trivial. Also, the model you are describing, sounds like major breaking
>> change.
>>
>> On Fri, Oct 23, 2009 at 1:26 PM, Jochen Theodorou <blackdrag@...> wrote:
>>> of course it would be possible to achieve that but it would require changes.
>>> For example I would add a transform, that checks the code for being free of
>>> side effects. All side effect free parts can be executed and rolled back. If
>>> during execution you meet a part with side effect you have to react
>>> accordingly by synchronization or with for example an exception. I would use
>>> annotations as marker for methods that are itself side effect free and any
>>> java code would by default be not side effect free. Then of course you
>>> cannot use normal lists and maps anymore, unless they remain unchanged,
>>> which I would ensure through a special class... and on and on. This model is
>>> quite different from the normal execution model we have in Groovy, but it
>>> can be done, and it can be done looking mostly native. I just don't have the
>>> time to realize something like that.
>>>
>>> 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
>>>
>>>
>>>
>>
>>
>>
>> --
>> Omnem crede diem tibi diluxisse supremum.
>>
>> ---------------------------------------------------------------------
>> 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]

Hamlet D'Arcy schrieb:

>>> real time check of a block code to ensure it's side effect free? that sounds
>>> non-trivial.
>
> Has anyone read the "Verifiable functional purity in java" paper on
> ACM? http://portal.acm.org/citation.cfm?id=1455770.1455793
>
> If my memory serves correctly, the authors defined an annotation like
> @SideEffectFree and then the compiler enforced that only other side
> effect free functions could be called within a section maked @Pure.
> (or something akin to that). Then provided a map file stating what
> parts of the JDK (and other libraries) are side effect free.

ah, interesting... That is much according to my thought, only that I
have it dynamic, while they try to solve it static. The idea I have is
more or less from the Hashkell presentation last year on the JVM
language summit. There they tried the static way too. And I tried to
find a reasonable way to do it dynamic.

> It sounds like you want something similar: you want to enforce a type
> system attribute (immutability) within a graph of objects. But you
> want to do it at runtime instead of compile time.

Well I focus more on the execution model, since it is a dynamic approach
and since my idea is more transaction based.

> Doesn't the dynamic nature of Groovy render this task impossible? Can
> you really trace all dependencies of a class (both field and method
> invocations) to make sure only other @Immutable entities are
> referenced? As stated before, the setX notation of the bean spec is a
> convention not a contract.

Well, I make this different. If and how a block can be split up in
several parallel transactions is decided by the compiler. During a
transaction I am allowed to call only side effect free methods (SEFM). A
block is SEFM if it contains only SEFM operations. A emthod is SEFM if
it contains only SEFM blocks. All method calls at compile time are seen
as SEFM. Any write access to global data makes the block no longer SEFM.
A setter is not SEFM, because it sets a field. A getter is to be seen as
SEFM if it only reads a field. A constructor is side effect free if it
sets only final fields. So with this SEFM criteria I get immutable
automatically, without having to check object graphs.


Of course the check for being SEFM has to be done partially by the
Groovy runtime. Since on each mehod call I have to check if the method I
call has the SEFM criteria set or not. But such a check would be easy to
include in the Groovy runtime and without any bigger performance penalty.

With this alone I don't get parallel execution thoough. A compiler may
use all operations of the method and put each one in its own
transaction. If the transaction can be executed without exception, then
the transaction succeeded. If all transactions succeeded, then I can use
the sub transactions results to build my return value. If an exception
happened that is showing a non SEFM method would be called, I roll back
all transactions.

That of course means, that calling any Java code will per default fail
unless it has been annotated accordingly.

I am sure @SideEffectFree has more or less the same idea, but the
difference is that I don't relay on the compile time check only. Well...
the dynamic approach ;)

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

[Jochen Theodorou]

Wilson MacGyver schrieb:
> real time check of a block code to ensure it's side effect free? that sounds
> non-trivial. Also, the model you are describing, sounds like major breaking
> change.

see my answer to Aley... I don't think it would be a major breaking
change. It is a optional execution model. Maybe it could be developed
into a general one, that depends on what to do when I see a method, that
is not side effect free. If I define a global transaction, then while
being in this I wouldn't need to roll back. This could be done by
checking a thread local, if I deine that all parallel transactions have
be executed in a thread per transaction. I am positive such a model
could work. If it works efficient is the question. But I don't think it
would have a too bad influence.

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

[Alex Tkachman]

When I think on side-effect free methods in Java I always killed by
static class initializers, which can be called practically at any
moment and most probably can't be caught by static code analisis

On Sat, Oct 24, 2009 at 6:38 PM, Jochen Theodorou <blackdrag@...> wrote:

> Hamlet D'Arcy schrieb:
>>>>
>>>> real time check of a block code to ensure it's side effect free? that
>>>> sounds
>>>> non-trivial.
>>
>> Has anyone read the "Verifiable functional purity in java" paper on
>> ACM? http://portal.acm.org/citation.cfm?id=1455770.1455793
>>
>> If my memory serves correctly, the authors defined an annotation like
>> @SideEffectFree and then the compiler enforced that only other side
>> effect free functions could be called within a section maked @Pure.
>> (or something akin to that). Then provided a map file stating what
>> parts of the JDK (and other libraries) are side effect free.
>
> ah, interesting... That is much according to my thought, only that I have it
> dynamic, while they try to solve it static. The idea I have is more or less
> from the Hashkell presentation last year on the JVM language summit. There
> they tried the static way too. And I tried to find a reasonable way to do it
> dynamic.
>
>> It sounds like you want something similar: you want to enforce a type
>> system attribute (immutability) within a graph of objects. But you
>> want to do it at runtime instead of compile time.
>
> Well I focus more on the execution model, since it is a dynamic approach and
> since my idea is more transaction based.
>
>> Doesn't the dynamic nature of Groovy render this task impossible? Can
>> you really trace all dependencies of a class (both field and method
>> invocations) to make sure only other @Immutable entities are
>> referenced? As stated before, the setX notation of the bean spec is a
>> convention not a contract.
>
> Well, I make this different. If and how a block can be split up in several
> parallel transactions is decided by the compiler. During a transaction I am
> allowed to call only side effect free methods (SEFM). A block is SEFM if it
> contains only SEFM operations. A emthod is SEFM if it contains only SEFM
> blocks. All method calls at compile time are seen as SEFM. Any write access
> to global data makes the block no longer SEFM. A setter is not SEFM, because
> it sets a field. A getter is to be seen as SEFM if it only reads a field. A
> constructor is side effect free if it sets only final fields. So with this
> SEFM criteria I get immutable automatically, without having to check object
> graphs.
>
>
> Of course the check for being SEFM has to be done partially by the Groovy
> runtime. Since on each mehod call I have to check if the method I call has
> the SEFM criteria set or not. But such a check would be easy to include in
> the Groovy runtime and without any bigger performance penalty.
>
> With this alone I don't get parallel execution thoough. A compiler may use
> all operations of the method and put each one in its own transaction. If the
> transaction can be executed without exception, then the transaction
> succeeded. If all transactions succeeded, then I can use the sub
> transactions results to build my return value. If an exception happened that
> is showing a non SEFM method would be called, I roll back all transactions.
>
> That of course means, that calling any Java code will per default fail
> unless it has been annotated accordingly.
>
> I am sure @SideEffectFree has more or less the same idea, but the difference
> is that I don't relay on the compile time check only. Well... the dynamic
> approach ;)
>
> 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]

Alex Tkachman schrieb:
> When I think on side-effect free methods in Java I always killed by
> static class initializers, which can be called practically at any
> moment and most probably can't be caught by static code analisis

they are called when the class is first initialized statically and only
once per class loader. For multithreading those have special rules in
the Java memory model, so they don't cause problems. In that respect I
think they are no threat unless you distribute the class on multiple
class loaders (for example multiple VMs). And th<t case they can really
cause a problem. Well... I hadn't ha them on my radar as well I must
confess.

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