"David Medlock" <ashleymedlock@no.spam.yahoo.com> wrote in message news:dbav61$1joa$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>> "Walter" <newshound@digitalmars.com> wrote in message news:dba6ee$vtj$1@digitaldaemon.com...
>>
>>>"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:db7e7e$143d$1@digitaldaemon.com...
>>>
>>>>Consider this:
>>>>// somwhere in class RecordsetView ....
>>>>
>>>>Field[] fields = myrecordset.fields;
>>>>
>>>>// and in galaxy far, far away....
>>>>
>>>>fields.sort; // pretty harmless, isn't it?
>>>
>>>The example code violates the basic COW principle of "Do not modify the referenced data unless you KNOW you are the sole reference to it."
>>>
>>>
>>
>>
>> The problem is that WE (team of developers)
>> DON'T KNOW in ALMOST ALL CASES is this variable
>> is a sole owner of array or no.
>> Is this particular array which arrived through three or four function
>> calls
>> modifiable or not? Just no time to trace what and where.
>> Practically all this will end up with "always dup before passing"
>> approach in design guidelines. Especially dealing with third party
>> libraries.
>>
>> Walter, I understand your position. You are lucky to
>> write compilers alone. You have a luxury to know each
>> variable origins. But for projects in 500000 lines of code
>> and 40 developers this COWboy's deal is not working.
>> Trust me.
>>
>> People in industry will not vote for D because of
>> it is extremely hard to assemble team of 40
>> developers all following COW rules.
>>
>> Andrew.
>>
>>
> Sorry I don't buy this.
>
> Companies adopt technology because of:
> 1. Support and longevity. Sun and MS will fix their software and they
> arent closing their doors anytime soon.

I've participated in the project which was oriented
on Microsoft JavaVM (the best Java VM and tools ever).
As you know Microsoft JavaVM is dead now due to
legal issues.

And original motivation was exactly yours.
Thunderclap in clear skies an all this ...

So you #1 is #1 for some extent. Those guys are not
buying this argument anymore as you can see.

The same happened with pretty much all COM/COM+ projects
recently. Someone in MS decided that COM/COM+ is evil
and Java alike .NET will be next silver bullet for next 4 years...


> 2. Availability of pools of programmers if they are needed. (this is the
> hard one for new languages)
> 3. Availability of tools.
> 4. Interoperability with their existing systems.
>
> #1 is always number one, but the others could be swapped depending on the company.  Middle management decision makers might listen to developer talk about feature B, but in the end those reasons end up deciding.
>
> There is absolutely nothing stopping you from making immutable Objects or Collections.  Walter has given you all the tools to do so.  He has also given you low level powerful tools to do other tasks.

I am personally pretty satisfied by what D have right now.
The only one thing missed: array and AA in D are Collections.
But there are no immutable versions of them. And this is a problem I am
talking
about. So I cannot use collection-as-a-value idiom.
Lack of this also follows to the fact that D has no strings in the
sense of C++/Java/C#.

Andrew.

"Walter" <newshound@digitalmars.com> wrote in message news:dbbflf$1u3s$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dbaa5l$130t$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:dba6ee$vtj$1@digitaldaemon.com...
>> > The example code violates the basic COW principle of "Do not modify the referenced data unless you KNOW you are the sole reference to it."
>> The problem is that WE (team of developers)
>> DON'T KNOW in ALMOST ALL CASES is this variable
>> is a sole owner of array or no.
>
> The corollary to the stated principle is "If you don't KNOW that you are
> the
> sole owner of the referenced data, then dup it before modifying it."
>
>> Is this particular array which arrived through three or four function
> calls
>> modifiable or not? Just no time to trace what and where. Practically all this will end up with "always dup before passing" approach in design guidelines. Especially dealing with third party libraries.
>
> No, "always dup before passing" is approaching the problem from the wrong direction, and is not COW. COW is "dup when you modify it". Never dup because someone ELSE might modify it. Dup when you DO modify it and you DON'T KNOW if you are the sole owner.

Stop, Walter, please don't waste your time on me.
I personally know what is COW, how to use it and where.

Basic principle in industry - either COW must be automatic for most commonly
used cases either enforced somehow.
Otherwise it will end up with dup everywhere.


>
>
>> Walter, I understand your position. You are lucky to
>> write compilers alone. You have a luxury to know each
>> variable origins. But for projects in 500000 lines of code
>> and 40 developers this COWboy's deal is not working.
>> Trust me.
>>
>> People in industry will not vote for D because of
>> it is extremely hard to assemble team of 40
>> developers all following COW rules.
>
> 

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbavgb$1jrn$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dbaa5l$130t$1@digitaldaemon.com...
>>
>> "Walter" <newshound@digitalmars.com> wrote in message news:dba6ee$vtj$1@digitaldaemon.com...
>>>
>>> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:db7e7e$143d$1@digitaldaemon.com...
>>>> Consider this:
>>>> // somwhere in class RecordsetView ....
>>>>
>>>> Field[] fields = myrecordset.fields;
>>>>
>>>> // and in galaxy far, far away....
>>>>
>>>> fields.sort; // pretty harmless, isn't it?
>>>
>>> The example code violates the basic COW principle of "Do not modify the referenced data unless you KNOW you are the sole reference to it."
>>>
>>
>> The problem is that WE (team of developers)
>> DON'T KNOW in ALMOST ALL CASES is this variable
>> is a sole owner of array or no.
>> Is this particular array which arrived through three or four function
>> calls
>> modifiable or not? Just no time to trace what and where.
>> Practically all this will end up with "always dup before passing"
>> approach in design guidelines. Especially dealing with third party
>> libraries.
>
> I don't know what you mean by "dup before passing". It should be "dup before writing". Passing data around is trivial. I agree if one doesn't take the time to know if something can be written to it should be duped but that is exactly what COW is about. To me the biggest problem of COW in D is "premature duping": the extra copies made by people trying to be prematurely defensive that wind up wasting GC resources. Like premature optimization, duping without writing is putting effort at the wrong location.
>
>> Walter, I understand your position. You are lucky to
>> write compilers alone. You have a luxury to know each
>> variable origins. But for projects in 500000 lines of code
>> and 40 developers this COWboy's deal is not working.
>> Trust me.
>
> Why? Java and Fortran seem to have large programs written in them. And Java doesn't even have COW. At least Fortran has the convention that you don't write to overlapping inputs.

What does it mean exactly: "And Java doesn't even have COW." ?
Java has Strings and other value referential types, we already discussed
this
many times...

>
>> People in industry will not vote for D because of
>> it is extremely hard to assemble team of 40
>> developers all following COW rules.
>
> It would be easy to assemble 40 C++ programmers to follow a slightly
> different COW: Const Or Walk. :-P
> To me the biggest things holding back D is the lack of tools, docs and
> libraries - the language is fine.

Think about this hypothesis:
"D has no strong libraries because its type system is not complete -
it has no readonly referential types including strings".

For example:

>> Why? Java and Fortran seem to have large programs written in them. And Java doesn't even have COW. At least Fortran has the convention that you don't write to overlapping inputs.
>
> What does it mean exactly: "And Java doesn't even have COW." ?
> Java has Strings and other value referential types, we already discussed
> this many times...

COW is a general principle that applies to more than just strings. Java strings are immutable but that doesn't mean Java programmers use COW- they use immutable strings. Everywhere else they dup like crazy just in case someone tries to overwrite their fields or arrays. You know this well since you've used the example of Swing and small classes like Point and Rectangle which get defensively dup'ed just because Java doesn't use COW.

>>> People in industry will not vote for D because of
>>> it is extremely hard to assemble team of 40
>>> developers all following COW rules.
>>
>> It would be easy to assemble 40 C++ programmers to follow a slightly
>> different COW: Const Or Walk. :-P
>> To me the biggest things holding back D is the lack of tools, docs and
>> libraries - the language is fine.
>
> Think about this hypothesis:
> "D has no strong libraries because its type system is not complete -
> it has no readonly referential types including strings".

or maybe "D has no strong libraries because we spend all our time arguing about const" :-)

> For example:
uhh - lost me.

"Walter" <newshound@digitalmars.com> wrote in message news:dbbflg$1u3s$2@digitaldaemon.com...
>
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbavgb$1jrn$1@digitaldaemon.com...
>> I don't know what you mean by "dup before passing". It should be "dup
> before
>> writing". Passing data around is trivial. I agree if one doesn't take the
>> time to know if something can be written to it should be duped but that
>> is
>> exactly what COW is about. To me the biggest problem of COW in D is
>> "premature duping": the extra copies made by people trying to be
> prematurely
>> defensive that wind up wasting GC resources. Like premature optimization, duping without writing is putting effort at the wrong location.
>
> Right.
>
> If there is a .dup in the code that is not obviously followed by writing
> to
> the data, then odds are pretty strong the code is not COW. For example,
>
>    return data.dup;
>
> and:
>
>    foo(data.dup);
>
> are almost certainly wrong (unless data is stack allocated).
>

Sure. But if you have foo declared exactly as

   void foo( char[] data);

and you don't have source code of that library the
only thing what you can do is foo(data.dup);

Problem is that for some data such buggy foo will not touch your data for other it will overwrite it.

If you are lucky that data.length is equal to allocation unit
then any data.length = something will create a copy (accidental COW)
if not then consequent data[x] = y; will damage your data.

In the complex projects it is the worst bug you can imagine.
- maintainance nightmare.
So you in real situation you'll have foo(data.dup); - just in case.

COW is a good wish - means that under the pressure of real timelines and complexity it will be just ignored by duping everything.

And COW missioners will be joyefuly eaten with songs and dances.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbblrv$22kg$1@digitaldaemon.com...
>>> Why? Java and Fortran seem to have large programs written in them. And Java doesn't even have COW. At least Fortran has the convention that you don't write to overlapping inputs.
>>
>> What does it mean exactly: "And Java doesn't even have COW." ?
>> Java has Strings and other value referential types, we already discussed
>> this many times...
>
> COW is a general principle that applies to more than just strings. Java strings are immutable but that doesn't mean Java programmers use COW- they use immutable strings. Everywhere else they dup like crazy just in case someone tries to overwrite their fields or arrays. You know this well since you've used the example of Swing and small classes like Point and Rectangle which get defensively dup'ed just because Java doesn't use COW.

So could you tell me why they are not using COW?
What is preventing them to use it?


>
>>>> People in industry will not vote for D because of
>>>> it is extremely hard to assemble team of 40
>>>> developers all following COW rules.
>>>
>>> It would be easy to assemble 40 C++ programmers to follow a slightly
>>> different COW: Const Or Walk. :-P
>>> To me the biggest things holding back D is the lack of tools, docs and
>>> libraries - the language is fine.
>>
>> Think about this hypothesis:
>> "D has no strong libraries because its type system is not complete -
>> it has no readonly referential types including strings".
>
> or maybe "D has no strong libraries because we spend all our time arguing about const" :-)

:) Remeber that first I did attempt to write such library and after that I've started screaming.

Seriosly: I am getting almost once per two weeks letter
like: "We need a fast GUI for our application.
Preferrably platform independent,etc.
UI forms are stored in DB as HTML - total
2000 different forms. Development will be outsourced in ....
What would you recommend?"

I simply cannot recommend Harmonia now for that.
This "outsourced in..." is too far from Canada and
I physically cannot sing that song about the cow.
And Canada provide no other COW enforcment tools like
ballistic missiles or something like this. Three battalions
of humanitarian aid forces. This is it and extremely good -
correctly designed type system.

On Sat, 16 Jul 2005 10:17:01 -0700, Walter <newshound@digitalmars.com> wrote:
> "Ben Hinkle" <ben.hinkle@gmail.com> wrote in message
> news:dbavgb$1jrn$1@digitaldaemon.com...
>> I don't know what you mean by "dup before passing". It should be "dup
> before
>> writing". Passing data around is trivial. I agree if one doesn't take the
>> time to know if something can be written to it should be duped but that is
>> exactly what COW is about. To me the biggest problem of COW in D is
>> "premature duping": the extra copies made by people trying to be
> prematurely
>> defensive that wind up wasting GC resources. Like premature optimization,
>> duping without writing is putting effort at the wrong location.
>
> Right.
>
> If there is a .dup in the code that is not obviously followed by writing to
> the data, then odds are pretty strong the code is not COW. For example,
>
>     return data.dup;

Agreed.

> and:
>
>     foo(data.dup);

Not certain, foo might be:
  foo(inout char[] param);

right? you can't tell at this stage.

Further the data referenced by the 'data' array can be modified in this function:
  foo(char[] param);

It is not 'readonly' only the array is, right?

Regan

>> and:
>>
>>     foo(data.dup);
>
> Not certain, foo might be:
>   foo(inout char[] param);
>
> right? you can't tell at this stage.

Don't dup here since foo will dup if it needs to. You are probably assuming
that foo will change param but if foo does not obey COW it will document it
so that you can dup even with foo(char[] param). For example the
std.stream.Stream.readLine(char[] buffer) takes a regular char[] input and
documents that it will fill the buffer without dup'ing. That is, it
explicitly tells the user it does not use COW.
ps - yes, Andrew, I know that if the author of foo forgot to mention the
fact that it didn't obey COW that it would step on param so you don't have
to post :-)

> Further the data referenced by the 'data' array can be modified in this
> function:
>   foo(char[] param);
>
> It is not 'readonly' only the array is, right?

Can you give a more concrete example? If foo changes "data" then it should document that. COW doesn't apply to functions that explicitly say they don't obey COW (not surprisingly). If a function doesn't say it disobeys COW then D programmers are free to assume it obeys COW - that's "the D way".

On Sat, 16 Jul 2005 20:54:02 -0400, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>>> and:
>>>
>>>     foo(data.dup);
>>
>> Not certain, foo might be:
>>   foo(inout char[] param);
>>
>> right? you can't tell at this stage.
>
> Don't dup here since foo will dup if it needs to. You are probably assuming that foo will change param

No, I was simply saying if you look at "foo(data.dup)" you do not know if the param is "in" or "inout". That piece of info would tell you if the function was *intending* to modify the param or not. However if it was "in" and thus not intending to modify the param it still might, accidently (bug) or illegally (bug, the programmer forgot the inout)

> but if foo does not obey COW it will document it

How?

> so that you can dup even with foo(char[] param). For example the
> std.stream.Stream.readLine(char[] buffer) takes a regular char[] input and
> documents that it will fill the buffer without dup'ing. That is, it
> explicitly tells the user it does not use COW.

I dislike this and view it as wrong. The function declaration IMO should be "std.stream.Stream.readLine(inout char[] buffer)"

> ps - yes, Andrew, I know that if the author of foo forgot to mention the
> fact that it didn't obey COW that it would step on param so you don't have to post :-)

Mistakes, those things we are trying to reduce, wouldn't it be nice if the compiler helped a little here?
Some sort of enforcement of readonly for "in" would reduce errors at little or no cost as far as I can see.

>> Further the data referenced by the 'data' array can be modified in this
>> function:
>>   foo(char[] param);
>>
>> It is not 'readonly' only the array is, right?
>
> Can you give a more concrete example?

void foo(char[] param) { param[0] = 'a'; }

> If foo changes "data" then it should document that.

Definately, the *compiler* should point out this error.

> COW doesn't apply to functions that explicitly say they don't obey COW (not surprisingly).

Not sure what you mean here, does "void foo(char[] param)" "explicitly say" it doesn't obey COW? I don't think it says anything WRT to COW. What it says to me is that it will *read* and not *modify* the parameter I pass it, however I *know* that is not guaranteed currently.

Of course, you're reffering to documentation at this point. Wouldn't it be nicer if the information was a requirement of the function declaration, which IMO it could/would be if:
 - in was readonly and enforced

thus requring the above function to be "void foo(inout char[] param)" or for the modification to be removed, thus correcting the *bug* in the function.

> If a function doesn't say it disobeys COW then D programmers are free to assume it obeys COW - that's "the D way".

Which is 'nice' but hardly comforting if you're looking for the *bug* that mutates some of your data *somewhere* in a large program. All I'm saying is that it would be *nice* to have some help ensuring we (and others) use COW correctly.

An ideal like COW is good, having no support in holding to that ideal is not good. IMO. To be clear I am not questioning the ideal, I *like* this ideal. The problem is not the ideal itself it's the support we have for that ideal.

Regan

In article <dbca7d$2gas$1@digitaldaemon.com>, Ben Hinkle says...
>
>>> and:
>>>
>>>     foo(data.dup);
>>
>> Not certain, foo might be:
>>   foo(inout char[] param);
>>
>> right? you can't tell at this stage.
>
>Don't dup here since foo will dup if it needs to. You are probably assuming
>that foo will change param but if foo does not obey COW it will document it
>so that you can dup even with foo(char[] param). For example the
>std.stream.Stream.readLine(char[] buffer) takes a regular char[] input and
>documents that it will fill the buffer without dup'ing. That is, it
>explicitly tells the user it does not use COW.
>ps - yes, Andrew, I know that if the author of foo forgot to mention the
>fact that it didn't obey COW that it would step on param so you don't have
>to post :-)
>
>> Further the data referenced by the 'data' array can be modified in this
>> function:
>>   foo(char[] param);
>>
>> It is not 'readonly' only the array is, right?
>
>Can you give a more concrete example? If foo changes "data" then it should document that. COW doesn't apply to functions that explicitly say they don't obey COW (not surprisingly). If a function doesn't say it disobeys COW then D programmers are free to assume it obeys COW - that's "the D way".
>

Forgive me that drastic formulation, but COW "the D way" (documentation only,
no concept of ownership, auto_ptr ...) simply stinks. It's unsafe, why the
heck not stick with C programming if that's all that D proponents have to
say about this vital question? Don't get me wrong: D _is_ definitely a very
exciting language! I simply don't get how you (Ben, Walter, many others ...)
can be pleased with that "gentleman's agreement" esprit of COW that is currently
called for "save" D programming. 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).

No personal offense intended, just upset ...

Peace,
Carlos