In article <dbe3f9$p88$1@digitaldaemon.com>, Ben Hinkle says...
>
>Another comment:
>
>> Experience shows that it doesn't work in the
>> real world, and as much as I hate C++, I'd say that even the C++
>> const "solution" offers much more than your COWBGA (COW by gentleman's
>> agreement).
>
>I wouldn't be so quick to accept claims about industry experience or existing experience and apply them to D. I'm not aware of any other language that has GC and COW. Trying to practice COW in a non-GC world like C/C++ is hard to do so the barrier is too high. One can practice COW in a GC language like Java but it isn't done widely. So naturally if one is writing a library in Java and trying to decide upon COW or defensive-duping one will chose defensive-duping since most people won't expect COW. In D since everyone should expect COW it would be strange to *not* use COW.
>

I agree that not using COW would be alien to D as it is now. But, suppose
I'd be able to say "the returned array is readonly" by some compiler-enforced
keyword (part of the method signature, _not_ documentation), neither the caller
nor the API designer has to care about unnecessary duping and it would be a
clear contract (or "promise", from developer to developer). The current
situation will only lead to duping "just in case" and is unreliable (humans
fail) too. I'd see it as a not too small improvement, if we could at least say
"you need to make a copy here" and that is enforced by the compiler. I'm aware
that such compiler checks are not waterproof guarantees and could be bypassed
purposely, but I'm not asking for a 100% tight compiler proof here.
To express myself clearly: I'm not against COW per se, what I don't like (and
feel is dangerous "in the real world") is the "by gentleman's agreement"
approach to COW that D is taking right now.

Peace,
Carlos

In article <dbefq2$11oo$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>
>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbe3f9$p88$1@digitaldaemon.com...
>> Another comment:
>>
>>> Experience shows that it doesn't work in the
>>> real world, and as much as I hate C++, I'd say that even the C++
>>> const "solution" offers much more than your COWBGA (COW by gentleman's
>>> agreement).
>>
>> I wouldn't be so quick to accept claims about industry experience or existing experience and apply them to D. I'm not aware of any other language that has GC and COW.
>
>Sorry, I does not understand this statement.
>GC is builtin in D runtime - so "D has..."  is applicable here.
>Does D have builtin COW?

Yep, that's the point! In C++ COW is transparent to the caller/client of an API (copy made without him even being aware of it, that's why I mentioned auto_ptr in my original post). The situation in D is whole lotta different unfortunately ...

Peace,
Carlos


>
>> Trying to practice COW in a non-GC world like C/C++ is hard to do so the barrier is too high. One can practice COW in a GC language like Java but it isn't done widely. So naturally if one is writing a library in Java and trying to decide upon COW or defensive-duping one will chose defensive-duping since most people won't expect COW. In D since everyone should expect COW it would be strange to *not* use COW.
>
>Java authors were realists. (.NET also apply)  Probably this is the reason?
>As Java systems proven to work in projects of various scales then
>I believe this realistic assumption makes some sense. No?
>
>COW is a universal technique and used everywhere when
>it makes sense. Java (as D) allows only to do this manually
>this is why it is used in Java but not so widespread.
>
>C++ allows to automate COW algorithms - this is
>why COW can be used naturally in C++
>(e.g. http://doc.trolltech.com/3.3/shclass.html#3)
>
>More:
>
>1. The COW design pattern is quite orthogonal to the problem of read-only arrays and pointers.
>
>char[#] toUpper( char[#] str )
>{
>   // 1) can be implemented using COW or not,
>   // 2) will not modify str.
>}
>
>2. COW is expensive in terms of effectiveness
>and size of final code:
>
>char[] toUpper( char[] str )
>{
>   bool changed;
>   for(...)
>   {
>       if( need to write ) // these if's are not
>         if( changed )     // desirable in the cycle body
>           //do new copy allocation
>         else
>          // proceed
>   }
>}
>
>3. In real cases and classes COW leads to non-trivial
>implementations - many consequences here:
>- demand of more skilled programmers.
>- maintainance, code reviews costs, etc.
>
>
>Andrew.
>
>
>

On Sun, 17 Jul 2005 13:11:02 -0400, Ben Hinkle wrote:

> Another comment:
> 
>> Experience shows that it doesn't work in the
>> real world, and as much as I hate C++, I'd say that even the C++
>> const "solution" offers much more than your COWBGA (COW by gentleman's
>> agreement).
> 
> I wouldn't be so quick to accept claims about industry experience or existing experience and apply them to D. I'm not aware of any other language that has GC and COW.

The interpreted language called 'Euphoria' has both, and neither are optional or manual. The language just does both for you and the coder is not even aware of what's happening in the background.

-- 
Derek Parnell
Melbourne, Australia
18/07/2005 7:36:17 AM

>> I wouldn't be so quick to accept claims about industry experience or
>> existing experience and apply them to D. I'm not aware of any other
>> language
>> that has GC and COW.
>
> The interpreted language called 'Euphoria' has both, and neither are optional or manual. The language just does both for you and the coder is not even aware of what's happening in the background.

True - I meant user-enforced COW. Another example of a language like the one
you mention is MATLAB. In MATLAB all data has value semantics enforced by
MATLAB using COW without the user ever knowing. For example the code
  x = zeros(100);
  y = x;
makes a 100x100 matrix of zeros and makes a shared-data copy in y. The line
  y(10,10) = 1;
will copy the data to a new 100x100 matrix and set element (10,10) to 1.
MATLAB also manages all memory automatically.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dbefq2$11oo$1@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbe3f9$p88$1@digitaldaemon.com...
>> Another comment:
>>
>>> Experience shows that it doesn't work in the
>>> real world, and as much as I hate C++, I'd say that even the C++
>>> const "solution" offers much more than your COWBGA (COW by gentleman's
>>> agreement).
>>
>> I wouldn't be so quick to accept claims about industry experience or existing experience and apply them to D. I'm not aware of any other language that has GC and COW.
>
> Sorry, I does not understand this statement.
> GC is builtin in D runtime - so "D has..."  is applicable here.
> Does D have builtin COW?

I don't see what your confusion is about - of course D doesn't have builtin COW. I think you know that. Are you confused by my use of the tem "language" to mean both what a compiler will enforce and what the conventions "enforce"? I assume you are just being argumentative here.

>> Trying to practice COW in a non-GC world like C/C++ is hard to do so the barrier is too high. One can practice COW in a GC language like Java but it isn't done widely. So naturally if one is writing a library in Java and trying to decide upon COW or defensive-duping one will chose defensive-duping since most people won't expect COW. In D since everyone should expect COW it would be strange to *not* use COW.
>
> Java authors were realists. (.NET also apply)  Probably this is the reason?

or they were wimps and gave into the naysayers without testing it out first :-)

> As Java systems proven to work in projects of various scales then I believe this realistic assumption makes some sense. No?

Defensive dup'ing isn't a disaster - it just reduces performance.

> COW is a universal technique and used everywhere when
> it makes sense. Java (as D) allows only to do this manually
> this is why it is used in Java but not so widespread.
>
> C++ allows to automate COW algorithms - this is
> why COW can be used naturally in C++
> (e.g. http://doc.trolltech.com/3.3/shclass.html#3)

<shudder> :-)

> More:
>
> 1. The COW design pattern is quite orthogonal to the problem of read-only arrays and pointers.
>
> char[#] toUpper( char[#] str )
> {
>   // 1) can be implemented using COW or not,
>   // 2) will not modify str.
> }

The need for read-only arrays is reduced by COW, though. The question is if the need is great enough to make it worth-while.

> 2. COW is expensive in terms of effectiveness
> and size of final code:
>
> char[] toUpper( char[] str )
> {
>   bool changed;
>   for(...)
>   {
>       if( need to write ) // these if's are not
>         if( changed )     // desirable in the cycle body
>           //do new copy allocation
>         else
>          // proceed
>   }
> }

Maybe it's just me but that doesn't look too expensive to me. If one is really concerned about the if's the for loop can be explicitly broken up but that would be a last resort optimization.

> 3. In real cases and classes COW leads to non-trivial
> implementations - many consequences here:
> - demand of more skilled programmers.
> - maintainance, code reviews costs, etc.

A system using an equal mix of COW and non-COW will require more effort to maintain IMHO than one that consistently applies one style as much as possible. Non-COW code should be used when one is reasonably certain performance will be a concern.