Paralysis of analysis -- the value/ref dilemma

[Andrei Alexandrescu]

On 12/15/10 11:05 AM, spir wrote:
> What I'm trying to fight is beeing forced to implement semantics
> values as concrete ref elements. This is very bad, a kind of
> conceptual distortion (the author of XL calls this semantic mismatch)
> that leads to much confusion.
[snip example]

> Conceptually, we absolutely need both.
> Again the ref/value semantic duality is independant from data types.
> If the language provides one kind only, we have to hack, to cheat
> with it.

Both are good. The question is which should be the "default" one and 
what should be the "other" one.

Your example is from a class of examples that basically say: a mutable 
reference object in a struct with value semantics is trouble. That is:

struct Widget // value type
{
     ...
     Array!Color colorMap; // oops, undue aliasing
}

That is correct. There are two solutions I envision:

1. Define a Value wrapper in std.container or std.typecons:

struct Widget // value type
{
     ...
     Value!(Array!Color) colorMap; // clones upon copying
}

2. Define this(this)

struct Widget // value type
{
     ...
     Array!Color colorMap; // manually cloned upon copying
     this(this) {
         colorMap = colorMap.clone;
     }
}

Note that if Widget is a class there is no such problem. The entire 
issue applies to designing value types.

> There is a special case in non-OO-only cisconstances: sometimes an
> element is passed as parameter while it is conceptually the "object"
> (in common sense) on which an operation applies (~ OO receiver). In
> OO, it would be passed by ref precisely to allow it beeing changed,
> even if it is a plain value (this prevents creating a new value at
> every tiny chenge, as opposed to immutability). But this relevant
> distinction between object of an operation (what) and true parameters
> (how) does not exist in plain function-based style: func(object,
> param1, param12); So that we have to pass the object by ref when the
> operation is precisely here to modify it. But conceptually it is  not
> a parameter.

I don't understand this part.


Andrei