Good terminology for setting up effectively immutable objects?

[Matthias Ernst]

Hi,

often I neither want a huge (number of) constructor(s) nor want to
jump through hoops of using a Builder to guarantee final-ness of my
object's dependencies but want to rely on effective immutability
instead. I want to rely on my clients' common sense that anything that
is not documented as changeable should not be changed during use. I.e.
a number of setters that they may only call a) before starting to use
the object and b) before publishing it to other threads.

Is there a concise term to document this? I don't want to repeat that
sermon above all over. @SetupMethod?
Sorry if this can be found in JCIP. I don't have one handy right now.

Thanks
Matthias
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[tpeierls]

I've been griping about the lack of a consensus (let alone a standard) for this in various places. It's not in JCiP. I think it would be good to collect ideas, so I added your message to the Java Concurrency wiki and started a list. Interested parties please add to and comment on the list.

http://artisans-serverintellect-com.si-eioswww6.com/default.asp?W151

--tim

On Mon, Apr 28, 2008 at 6:48 AM, Matthias Ernst <matthias@...> wrote:

Hi,

often I neither want a huge (number of) constructor(s) nor want to
jump through hoops of using a Builder to guarantee final-ness of my
object's dependencies but want to rely on effective immutability
instead. I want to rely on my clients' common sense that anything that
is not documented as changeable should not be changed during use. I.e.
a number of setters that they may only call a) before starting to use
the object and b) before publishing it to other threads.

Is there a concise term to document this? I don't want to repeat that
sermon above all over. @SetupMethod?
Sorry if this can be found in JCIP. I don't have one handy right now.

Thanks
Matthias
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Mark Thornton]

Matthias Ernst wrote:

> Hi,
>
> often I neither want a huge (number of) constructor(s) nor want to
> jump through hoops of using a Builder to guarantee final-ness of my
> object's dependencies but want to rely on effective immutability
> instead. I want to rely on my clients' common sense that anything that
> is not documented as changeable should not be changed during use. I.e.
> a number of setters that they may only call a) before starting to use
> the object and b) before publishing it to other threads.
>  

While I have written this sort of code often enough, I can't avoid the
feeling that I should have used the builder pattern in most of the
cases. In fact all of them, should probably have been genuinely
immutable and not merely effectively immutable. Can we find a way to
make the builder pattern more palatable?

Mark Thornton


_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Jed Wesley-Smith]

I thoroughly agree. Working on a large code-base with init methods
throughout, there is a lot to like about the guarantees that true
immutability gives you. Firstly you ensure that your objects are
correctly set up and all invariants are honoured. Secondly, you get
memory visibility guarantees regarding the initial values that you need
safe publication otherwise to achieve (well, true immutability gives you
safe publication without extra effort). Publication errors are some of
the most painful to diagnose and reproduce. You can also then make sure
that any builders are stack local.

As to making builder more palatable, whenever I have pointed out all the
problems with effective immutability and safe publication and the
potential gotchas of getting it wrong, the builder overhead starts to
look very attractive.

cheers,
jed.

Mark Thornton wrote:

> Matthias Ernst wrote:
>  
>> Hi,
>>
>> often I neither want a huge (number of) constructor(s) nor want to
>> jump through hoops of using a Builder to guarantee final-ness of my
>> object's dependencies but want to rely on effective immutability
>> instead. I want to rely on my clients' common sense that anything that
>> is not documented as changeable should not be changed during use. I.e.
>> a number of setters that they may only call a) before starting to use
>> the object and b) before publishing it to other threads.
>>  
>>    
> While I have written this sort of code often enough, I can't avoid the
> feeling that I should have used the builder pattern in most of the
> cases. In fact all of them, should probably have been genuinely
> immutable and not merely effectively immutable. Can we find a way to
> make the builder pattern more palatable?
>
> Mark Thornton
>  

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Matthias Ernst]

I understand the concern. I just don't see adding this code overhead
to my code. I think that safe publication and happens-before are
wonderful abstractions, good to reason about and I'm so glad we have
them. I believe this should be the canonical style. Unsafe publication
should be forbidden except for the few core cases that required having
it in the first place.

And that leads to what's bugging me (never quite having been able to
phrase it) about your and similar arguments that came up in
discussions about safety of servlet initialization and DI containers:
I know it's defensive engineering but at the same time it's positive
reinforcement for unsafe publication practices. It appears to shifts
responsibility from the client and makes components even more
expensive to write. I would like to take an absolute stance - client
code doing unsafe publication is buggy and must be fixed. I'm not
willing to go out of my way in order to safeguard against other
people's bugs.

Having said that, I love final fields and I've been dreaming about a
way to have _clients_ initialize blank final fields. Something like:

X x = new X() {{
 foo = bar;
}};

where foo is a blank final unassigned in the X() constructor. But
haven't thought that through.

So anyone that does have a name for requiring setters to be only
called during the "setup phase"?

Cheers
Matthias

On Tue, Apr 29, 2008 at 2:48 AM, Jed Wesley-Smith <jed@...> wrote:

> I thoroughly agree. Working on a large code-base with init methods
>  throughout, there is a lot to like about the guarantees that true
>  immutability gives you. Firstly you ensure that your objects are
>  correctly set up and all invariants are honoured. Secondly, you get
>  memory visibility guarantees regarding the initial values that you need
>  safe publication otherwise to achieve (well, true immutability gives you
>  safe publication without extra effort). Publication errors are some of
>  the most painful to diagnose and reproduce. You can also then make sure
>  that any builders are stack local.
>
>  As to making builder more palatable, whenever I have pointed out all the
>  problems with effective immutability and safe publication and the
>  potential gotchas of getting it wrong, the builder overhead starts to
>  look very attractive.
>
>  cheers,
>  jed.
>
>
>
>  Mark Thornton wrote:
>  > Matthias Ernst wrote:
>  >
>  >> Hi,
>  >>
>  >> often I neither want a huge (number of) constructor(s) nor want to
>  >> jump through hoops of using a Builder to guarantee final-ness of my
>  >> object's dependencies but want to rely on effective immutability
>  >> instead. I want to rely on my clients' common sense that anything that
>  >> is not documented as changeable should not be changed during use. I.e.
>  >> a number of setters that they may only call a) before starting to use
>  >> the object and b) before publishing it to other threads.
>  >>
>  >>
>  > While I have written this sort of code often enough, I can't avoid the
>  > feeling that I should have used the builder pattern in most of the
>  > cases. In fact all of them, should probably have been genuinely
>  > immutable and not merely effectively immutable. Can we find a way to
>  > make the builder pattern more palatable?
>  >
>  > Mark Thornton
>  >
>
>  _______________________________________________
>  Concurrency-interest mailing list
>  Concurrency-interest@...
>  http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Mark Thornton]

Matthias Ernst wrote:
> Having said that, I love final fields and I've been dreaming about a
> way to have _clients_ initialize blank final fields. Something like:
>
> X x = new X() {{
>  foo = bar;
> }};
>
>  
class X {
    final Type foo; ...
   private X(Builder b) {
       foo = b.foo;
    }

  static class Builder {
     protected Type foo;

    public X create() {return new X(this);}
  }
}


...

X x = new X.Builder() {
    public X create() {
       foo = bar;
       return super.create();
    }.create();


No doubt a shorter version is possible.

Mark
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

[Tom Hawtin]

Matthias Ernst wrote:
>
> So anyone that does have a name for requiring setters to be only
> called during the "setup phase"?

It think "two-phase construction" (or initialization) is usual. Usually
in the context of "antipatterns".

Tom Hawtin
_______________________________________________
Concurrency-interest mailing list
Concurrency-interest@...
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest