Paralysis of analysis -- the value/ref dilemma

[Bruno Medeiros]

On 15/12/2010 17:05, spir wrote:
> On Wed, 15 Dec 2010 09:56:36 -0600
> Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org>  wrote:
>
>> Optimization (or pessimization) is a concern, but not my primary one. My
>> concern is: most of the time, do you want to work on a container or on a
>> copy of the container? Consider this path-of-least-resistance code:
>>
>> void fun(Container!int c) {
>>       ...
>>       c[5] += 42;
>>       ...
>> }
>>
>> Question is, what's the most encountered activity? Should fun operate on
>> whatever container it was passed, or on a copy of it? Based on extensive
>> experience with the STL, I can say that in the overwhelming majority of
>> cases you want the function to mess with the container, or look without
>> touch (by means of const). It is so overwhelming, any code reviewer in
>> an STL-based environment will raise a flag when seeing the C++
>> equivalent to the code above - ironically, even if fun actually does
>> need a copy of its input! (The common idiom is to pass the container by
>> constant reference and then create a copy of it inside fun, which is
>> suboptimal.)
>
> I do agree.
>
> When a container is passed as parameter
> * either it is a value in meaning and should be left unchanged (-->  so that the compiler can pass it as "constant reference")
> * or it means an entity with identity, it makes sense to change it, and it should be implemented as a ref.
>
> 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.

As someone who takes conceptual cleanliness very seriously, I had to 
chime in, as I don't quite agree with your points.

> Example of semantic distinction:
> Take a palette of predefined colors (red, green,..) used to draw visual widgets. In the simple case, colors are plain information (=values), and the palette (a collection) as well. In this case, every widget holds its own subset of colors used for each part of itself. Meaning copies. Chenging a given color assigned to a widget should&  does not affect others.
> Now, imagine this palette can be edited "live" by the user, meaning redefining the components of re, green,... This time, the semantics may well be that such changes should aaffect all widgets, including already defined ones. For this, the palette must be implemented as an "entity", and each as well. But the reason for this is that the palette does not mean the same thing at all: instead of information about an aspect (color) of every widget, we have now a kind of container of color _sources_. Instead of color values, the widget fields point to kinds of paint pots; these fields should not be called "color".
> [It is not always that simple to find real-world metaphors helping us and correctly understand what we have to model and write into programs. A program's world is not at all reality, not even similar to it, even in the (minority of) cases where it models reality. In this case, "color" is misleading.]
>
> In the first case, palette must be a value, in the second case it must be a ref. There is no way to escape the dilemma about having value or ref collections. 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.
>

The discussion here is simply what should be the common, default case. 
Who said we can't have both? What's the justification for "If the 
language provides one kind only, we have to hack, to cheat with it." ??


Also, the things you say about collections being ref or value is badly 
worded. First of all, considering a collection on its own, there is no 
right answer to whether the collection /should/ have value or reference 
semantics. The statement is meaningless.
Only when a collection is associated with some other object does this 
question make sense. Is the collection part-of/owned-by the object, or 
it is merely referenced by it? So taking your example, does a Widget 
each have their own Palette of Colors, or is there only one common 
Palette? The answer depends on your domain, this is a modeling/design 
problem, not a language design one.
The only thing the language should strive for is being able to 
represent/code both possible designs as well as possible (in a clear 
way, less bug prone, etc.).

-- 
Bruno Medeiros - Software Engineer