Clarification on migration to value types and boxed vs unboxed representations

[Vitaly Davidovich]

What are the "far too many" downsides? The lost writes can happen if not
careful, but what else? I'm assuming though if mutable value types were
possible, then language and VM would allow passing them by ref.

Sent from my phone
On Jan 6, 2015 5:12 AM, "Stephen Colebourne" <scolebourne at joda.org> wrote:

> On 6 January 2015 at 01:58, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> > Mutable structs aren't used all that often in c# but there are times when
> > they're very useful.
>
> When I've thought about this, the first use case for mutable I came up
> with was property objects. These allow code like:
>
> class Person {
>   public final Property<Strring> surname;
> }
> String surname = person.surname.get();
> person.surname.set("MySurname");
> Property<String> p = person.surname;
>
> Here, Property is a mutable wrapper around the surname, hence the
> get() and set(). Today, this design is only suitable for the client
> side, as creating all the wrapper objects creates far too much garbage
> and churn for a server (tried it, was a car crash).
>
> However, despite the appeal of making this work via value types, I'm
> willing to agree that allowing mutability would have far too many
> otehr negative consequences. Thus I agree with the "only immutable"
> design direction.
>
> Stephen
>