August 01, 2005
In article <dclmn7$42s$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dclk4p$1o0$1@digitaldaemon.com...
>> In article <dclfvs$2usj$1@digitaldaemon.com>, Ben Hinkle says...
>>>
>>>
>>>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dcleqr$2ti5$1@digitaldaemon.com...
>>>> In article <dclba9$2pif$1@digitaldaemon.com>, Ben Hinkle says...
>>>>>
>>>>>
>>>>>"Derek Parnell" <derek@psych.ward> wrote in message news:a118xxgyuee7.t1828b9vk5du$.dlg@40tude.net...
>>>>> [snip]
>>>>>Besides those reasons writing "B.reverse" to me indicates you want to
>>>>>affect
>>>>>B hence no COW while "reverse(B)" says you want a reversed B hence COW.
>>>>>That's one reason why I don't really like the current syntax hack of
>>>>>being
>>>>>able to write B.tolower() to mean tolower(B).
>>>>
>>>> Utterly confusing!  reserve(b) and B.reverse have nothing in their name
>>>> to
>>>> imply
>>>> that either one copies the data.  By default COW should not happen.
>>>> Believe me,
>>>> look at .NET where everything is COW.  New memory allocations all over
>>>> the
>>>> place.  IMHO .dup is there for a reason, and nothing is preventing you
>>>> from
>>>> doing:
>>>>
>>>> foo.dup.reverse
>>>>
>>>> If somebody else comes along, they will knows you are copying the array.
>>>> It's
>>>> only 4 more characters of typing.  Plus no confusion as to what does cow
>>>> and
>>>> what doesn't.  I can copy the thing first with .dup if I want.  This
>>>> isn't
>>>> C
>>>> where it's 5 lines of code every time you need to copy an array!
>>>>
>>>> -Sha
>>>
>>>You've lost me. Are you proposing a change to any existing behavior or
>>>coding practice (ie COW)?
>>
>> I wasn't proposing a change at all.  I was disagreing with Derek.  I think
>> COW
>> is a bad thing for API functions to be doing mysteriously.  It leads to
>> crap
>> like this:
>>
>> foo = foo.Replace("Hello","");
>> dateFoo = dateFoo.AddDays(1);
>
>I didn't read Derek's post as proposing reverse use COW. He was pointing out that it doesn't.

You're right, he didn't.  I was contesting that tolower(b) and b.tolower should
do different things.

> It's too bad you see COW as mysterious.

I don't find anything mysterious about it. It's just not useful most every time I've had any dealing with COW functions.   If I want COW, I can dupe the object first.

>> If I want a duplicate something, in D, it's as easy as saying:
>> # foo2 = foo.dup.replace("Hello","");
>> (Not that replace is a valid property for char[]s, but you get my gist)
>>
>> This leads to effective memory use, and no confusion about:
>>
>> reverse(b), or b.reverse
>>
>> Which one does c-o-w?  The name certainly doesn't say, maybe by somebodies
>> reasoning it might make sense that one does cow and one doesn't.  But
>> certainly
>> not mine, from the information given.
>
>The statement about effective memory use only is true when the operation is guaranteed to change the string. If foo in the example didn't contain any Hellos then the dup would be wasteful.

I hope you're not implying that replace should only return a new instance if something was actually changed.  That is obsurd.  I would then need to check to see if it's given me back a reference to a new array before I could use it?

> Plus I'm surprised you don't see any
>difference between reverse(b) and b.reverse since it's common in OOP to interpret b.foo as acting on b while foo(b) is just some function of b.

Why don't you tell microsoft that.   Many of the examples I listed were from VB.NET, and do COW from member functions. Also, Just because it is common doesn't make it logical, consistent, or obvious to a somebody not familiar with these __unwritten__ agreements.

>> Also, you might say for consistency, always use cow.  But cow is not
>> always what
>> you want. Since there's no way to manually un-cowify it,  It would make
>> logical
>> sense to NEVER do cow, and let the programmer call dup first.
>
>That would be a big change in D style since many times you do not know if a dup will be needed or not (eg most of the functions in std.string might just return the original string).

If I'm understanding what you just said, let me say this:

As I said above, I think it's silly to have non-deterministic behavior from those functions.  When I say deterministic, I mean that I should be able to expect it to always return a duplicate string, or not.

-Sha


August 01, 2005
In article <dclls6$37o$1@digitaldaemon.com>, AJG says...
>
>Hi,
>
>>If I want a duplicate something, in D, it's as easy as saying:
>># foo2 = foo.dup.replace("Hello","");
>>(Not that replace is a valid property for char[]s, but you get my gist)
>
>Exactly.
>
>>This leads to effective memory use, and no confusion about:
>>reverse(b), or b.reverse
>>
>>Which one does c-o-w?  The name certainly doesn't say, maybe by somebodies reasoning it might make sense that one does cow and one doesn't.  But certainly not mine, from the information given.
>
>IMHO, and for consistency, it should never do COW. If a user wants to do COW, let the user do it. That's exactly what I mean by reference semantics, so it seems we are in agreement here.
>
>>Also, you might say for consistency, always use cow.  But cow is not always you want. Since there's no way to manually un-cowify it,  It would make logical sense to NEVER do cow, and let the programmer call dup first.
>
>Interestingly enough (and one of my points), .length does COW about half of the time, and there's no way to un-cowify it.

While I agree with you that it could be annoying, the problem is that arrays are really stack variables which have a reference member. (As you well know by now.)

So, in order to un-cowify .length we would have to make all arrays true references which contain references.  Also, that still doesn't fix array slices. We would ALWAYS need to dup when an array slice is made.  :(

However, there's an easy way to handle the first problem already:

char[] a = "Hello";
char[]* b = &a; // (I hope anyways, & shouldn't return a.ptr... I haven't
checked this.)
(*b).length = 10;
writef("%i", a.length);

Although array slices won't be fixed without a special array slice type.  So that it would know the start of the array and resize that.

>
>That's a great word, btw, un-cowify. It had me chuckling.

Thanks :)

-Sha


August 01, 2005
In article <1as80g46qpg5w$.1dfr6mqon4u1t$.dlg@40tude.net>, Derek Parnell says...
>
>On Mon, 1 Aug 2005 16:54:49 +0000 (UTC), Shammah Chancellor wrote:
>
>
>>>>>"Derek Parnell" <derek@psych.ward> wrote in message news:a118xxgyuee7.t1828b9vk5du$.dlg@40tude.net...
>>>>> [snip]
>>>>>Besides those reasons writing "B.reverse" to me indicates you want to
>>>>>affect
>>>>>B hence no COW while "reverse(B)" says you want a reversed B hence COW.
>>>>>That's one reason why I don't really like the current syntax hack of being
>>>>>able to write B.tolower() to mean tolower(B).
>
>> I was disagreing with Derek.  I think COW
>> is a bad thing for API functions to be doing mysteriously.  It leads to crap
>> like this:
>> 
>> foo = foo.Replace("Hello","");
>> dateFoo = dateFoo.AddDays(1);
>
>Hi Shammah,
>I wasn't actually saying that .reverse must use CoW. I was saying that it
>didn't and that fact seems go counter to Walter's general principle (as I
>understand it) about when to use Cow or not. I thought that one should use
>CoW if the code is actually changing the data *and* the data might be
>accessible to the calling routine. Thus as the .reverse will change the
>data for lengths > 1, and the data is probably accessible to the code using
>.reverse, one could have expected it to CoW.
>
>Of course, I might be misunderstanding that 'general principle' ;-)
>
>As the current behaviour is documented, we can cope with this seeming exception.

No,no I understood that.  I'm just being argumentative.  I don't agree with you that tolower(b) and b.tolower should do different things.  I don't agree that tolower(b) should even exist in the face of b.tolower.  It clutters up my namespace.  (Aside that user properties in D can't be added to a special char[] namespace =/ )

It just happened my example from VB was using class methods.  For example in NET in order to round a date up from seconds to 5 minutes, you need to allocate like 3 or 4 datetimes.  Of course you don't SEE this, but .AddDays, .AddSeconds etc. They all allocate a new datetime.

For example, in .NET in order to get tomorrow's date:

Dim tomorrow as String = DateTime.Now.Date.AddDays(1).ToLongDateString()

That required allocations of 3 dateTimes and a String.

I could completely be abusing the .NET Framework, but I searched far and wide and couldn't find an alternative that worked on the original.

This kind of crud is why I'm very opposed to COW. In class methods or global functions. If .NET had D style dupes and I really wanted to operate on a new object:

Dim tomorrow as String =
DateTime.Now.Duplicate.Date.AddDays(1).ToLongDateString()

One less allocation since AddDays didn't need/get it's own copy of the memory.

You might still cite tolower(b) instead of b.tolower as not being as rediculous as what .NET wants.  But I ask you thi: If somebody doesn't know your COW conventions, would they know the difference in what happens?  In any case arr.dup.tolower would fit the same purpose just fine, and it's more explicit.


-Sha




August 01, 2005
"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dcm4an$grn$1@digitaldaemon.com...
> In article <dclmn7$42s$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>
>>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dclk4p$1o0$1@digitaldaemon.com...
>>> In article <dclfvs$2usj$1@digitaldaemon.com>, Ben Hinkle says...
>>>>
>>>>
>>>>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dcleqr$2ti5$1@digitaldaemon.com...
>>>>> In article <dclba9$2pif$1@digitaldaemon.com>, Ben Hinkle says...
>>>>>>
>>>>>>
>>>>>>"Derek Parnell" <derek@psych.ward> wrote in message news:a118xxgyuee7.t1828b9vk5du$.dlg@40tude.net...
>>>>>> [snip]
>>>>>>Besides those reasons writing "B.reverse" to me indicates you want to
>>>>>>affect
>>>>>>B hence no COW while "reverse(B)" says you want a reversed B hence
>>>>>>COW.
>>>>>>That's one reason why I don't really like the current syntax hack of
>>>>>>being
>>>>>>able to write B.tolower() to mean tolower(B).
>>>>>
>>>>> Utterly confusing!  reserve(b) and B.reverse have nothing in their
>>>>> name
>>>>> to
>>>>> imply
>>>>> that either one copies the data.  By default COW should not happen.
>>>>> Believe me,
>>>>> look at .NET where everything is COW.  New memory allocations all over
>>>>> the
>>>>> place.  IMHO .dup is there for a reason, and nothing is preventing you
>>>>> from
>>>>> doing:
>>>>>
>>>>> foo.dup.reverse
>>>>>
>>>>> If somebody else comes along, they will knows you are copying the
>>>>> array.
>>>>> It's
>>>>> only 4 more characters of typing.  Plus no confusion as to what does
>>>>> cow
>>>>> and
>>>>> what doesn't.  I can copy the thing first with .dup if I want.  This
>>>>> isn't
>>>>> C
>>>>> where it's 5 lines of code every time you need to copy an array!
>>>>>
>>>>> -Sha
>>>>
>>>>You've lost me. Are you proposing a change to any existing behavior or
>>>>coding practice (ie COW)?
>>>
>>> I wasn't proposing a change at all.  I was disagreing with Derek.  I
>>> think
>>> COW
>>> is a bad thing for API functions to be doing mysteriously.  It leads to
>>> crap
>>> like this:
>>>
>>> foo = foo.Replace("Hello","");
>>> dateFoo = dateFoo.AddDays(1);
>>
>>I didn't read Derek's post as proposing reverse use COW. He was pointing
>>out
>>that it doesn't.
>
> You're right, he didn't.  I was contesting that tolower(b) and b.tolower
> should
> do different things.
>>> If I want a duplicate something, in D, it's as easy as saying:
>>> # foo2 = foo.dup.replace("Hello","");
>>> (Not that replace is a valid property for char[]s, but you get my gist)
>>>
>>> This leads to effective memory use, and no confusion about:
>>>
>>> reverse(b), or b.reverse
>>>
>>> Which one does c-o-w?  The name certainly doesn't say, maybe by
>>> somebodies
>>> reasoning it might make sense that one does cow and one doesn't.  But
>>> certainly
>>> not mine, from the information given.
>>
>>The statement about effective memory use only is true when the operation
>>is
>>guaranteed to change the string. If foo in the example didn't contain any
>>Hellos then the dup would be wasteful.
>
> I hope you're not implying that replace should only return a new instance
> if
> something was actually changed.

That is what I'm implying - and that's what many std.string functions do.

> That is obsurd.  I would then need to check to
> see if it's given me back a reference to a new array before I could use
> it?

why? The only time you would care is if you start modifying the array in-place.

>> Plus I'm surprised you don't see any
>>difference between reverse(b) and b.reverse since it's common in OOP to
>>interpret b.foo as acting on b while foo(b) is just some function of b.
>
> Why don't you tell microsoft that.   Many of the examples I listed were
> from
> VB.NET, and do COW from member functions.

Strings in VB.NET are immutable so I'm not surprised that methods return new strings - that's the definition of immutable. Mutable objects would interpret b.reverse as acting on b.

> Also, Just because it is common
> doesn't make it logical, consistent, or obvious to a somebody not familiar
> with
> these __unwritten__ agreements.

Unwritten in what sense? COW is documented in several places in D (though I would like even more documenation about it since it appears people don't know about it).

>>> Also, you might say for consistency, always use cow.  But cow is not
>>> always what
>>> you want. Since there's no way to manually un-cowify it,  It would make
>>> logical
>>> sense to NEVER do cow, and let the programmer call dup first.
>>
>>That would be a big change in D style since many times you do not know if
>>a
>>dup will be needed or not (eg most of the functions in std.string might
>>just
>>return the original string).
>
> If I'm understanding what you just said, let me say this:
>
> As I said above, I think it's silly to have non-deterministic behavior
> from
> those functions.  When I say deterministic, I mean that I should be able
> to
> expect it to always return a duplicate string, or not.

ok - everyone is entitled to their opinions. To me it's simpler to obey COW. Changing an array in-place is rare enough that special care is ok with me.


August 02, 2005
In article <dcmaak$l5m$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dcm4an$grn$1@digitaldaemon.com...
>> In article <dclmn7$42s$1@digitaldaemon.com>, Ben Hinkle says...
>>>
>>>
>>>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dclk4p$1o0$1@digitaldaemon.com...
>>>> In article <dclfvs$2usj$1@digitaldaemon.com>, Ben Hinkle says...
>>>>>
>>>>>
>>>>>"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dcleqr$2ti5$1@digitaldaemon.com...
>>>>>> In article <dclba9$2pif$1@digitaldaemon.com>, Ben Hinkle says...
>>>>>>>
>>>>>>>
>>>>>>>"Derek Parnell" <derek@psych.ward> wrote in message news:a118xxgyuee7.t1828b9vk5du$.dlg@40tude.net...
>>>>>>> [snip]
>>>>>>>Besides those reasons writing "B.reverse" to me indicates you want to
>>>>>>>affect
>>>>>>>B hence no COW while "reverse(B)" says you want a reversed B hence
>>>>>>>COW.
>>>>>>>That's one reason why I don't really like the current syntax hack of
>>>>>>>being
>>>>>>>able to write B.tolower() to mean tolower(B).
>>>>>>
>>>>>> Utterly confusing!  reserve(b) and B.reverse have nothing in their
>>>>>> name
>>>>>> to
>>>>>> imply
>>>>>> that either one copies the data.  By default COW should not happen.
>>>>>> Believe me,
>>>>>> look at .NET where everything is COW.  New memory allocations all over
>>>>>> the
>>>>>> place.  IMHO .dup is there for a reason, and nothing is preventing you
>>>>>> from
>>>>>> doing:
>>>>>>
>>>>>> foo.dup.reverse
>>>>>>
>>>>>> If somebody else comes along, they will knows you are copying the
>>>>>> array.
>>>>>> It's
>>>>>> only 4 more characters of typing.  Plus no confusion as to what does
>>>>>> cow
>>>>>> and
>>>>>> what doesn't.  I can copy the thing first with .dup if I want.  This
>>>>>> isn't
>>>>>> C
>>>>>> where it's 5 lines of code every time you need to copy an array!
>>>>>>
>>>>>> -Sha
>>>>>
>>>>>You've lost me. Are you proposing a change to any existing behavior or
>>>>>coding practice (ie COW)?
>>>>
>>>> I wasn't proposing a change at all.  I was disagreing with Derek.  I
>>>> think
>>>> COW
>>>> is a bad thing for API functions to be doing mysteriously.  It leads to
>>>> crap
>>>> like this:
>>>>
>>>> foo = foo.Replace("Hello","");
>>>> dateFoo = dateFoo.AddDays(1);
>>>
>>>I didn't read Derek's post as proposing reverse use COW. He was pointing
>>>out
>>>that it doesn't.
>>
>> You're right, he didn't.  I was contesting that tolower(b) and b.tolower
>> should
>> do different things.
>>>> If I want a duplicate something, in D, it's as easy as saying:
>>>> # foo2 = foo.dup.replace("Hello","");
>>>> (Not that replace is a valid property for char[]s, but you get my gist)
>>>>
>>>> This leads to effective memory use, and no confusion about:
>>>>
>>>> reverse(b), or b.reverse
>>>>
>>>> Which one does c-o-w?  The name certainly doesn't say, maybe by
>>>> somebodies
>>>> reasoning it might make sense that one does cow and one doesn't.  But
>>>> certainly
>>>> not mine, from the information given.
>>>
>>>The statement about effective memory use only is true when the operation
>>>is
>>>guaranteed to change the string. If foo in the example didn't contain any
>>>Hellos then the dup would be wasteful.
>>
>> I hope you're not implying that replace should only return a new instance
>> if
>> something was actually changed.
>
>That is what I'm implying - and that's what many std.string functions do.

Bah

>
>> That is obsurd.  I would then need to check to
>> see if it's given me back a reference to a new array before I could use
>> it?
>
>why? The only time you would care is if you start modifying the array in-place.

Exactly.  Quite often when I want to replace one thing, I want to replace ALOT
of things. (Or take any
other example.)  If each replace allocates a new string, that's inefficient.
Maybe I only want to copy it
once, and then modify it in place.   When .dup is only 4 extra characters per
instance of this, it does not
justify having two copies of every array function, one for cow and one for in
place.

>
>>> Plus I'm surprised you don't see any
>>>difference between reverse(b) and b.reverse since it's common in OOP to
>>>interpret b.foo as acting on b while foo(b) is just some function of b.
>>
>> Why don't you tell microsoft that.   Many of the examples I listed were
>> from
>> VB.NET, and do COW from member functions.
>
>Strings in VB.NET are immutable so I'm not surprised that methods return new strings - that's the definition of immutable. Mutable objects would interpret b.reverse as acting on b.

True. However, for mutable objects, would you like to duplicate every function
for COW and non-COW?
I find it less confusing to explicitly dup. (It also clutters my namespace
less!)

>
>> Also, Just because it is common
>> doesn't make it logical, consistent, or obvious to a somebody not familiar
>> with
>> these __unwritten__ agreements.
>
>Unwritten in what sense? COW is documented in several places in D (though I would like even more documenation about it since it appears people don't know about it).

There's barely any documentation for the API as it is.   And a footnote about
tolower( string ) on a man
page is not enough for me.

>>>> Also, you might say for consistency, always use cow.  But cow is not
>>>> always what
>>>> you want. Since there's no way to manually un-cowify it,  It would make
>>>> logical
>>>> sense to NEVER do cow, and let the programmer call dup first.
>>>
>>>That would be a big change in D style since many times you do not know if
>>>a
>>>dup will be needed or not (eg most of the functions in std.string might
>>>just
>>>return the original string).
>>
>> If I'm understanding what you just said, let me say this:
>>
>> As I said above, I think it's silly to have non-deterministic behavior
>> from
>> those functions.  When I say deterministic, I mean that I should be able
>> to
>> expect it to always return a duplicate string, or not.
>
>ok - everyone is entitled to their opinions. To me it's simpler to obey COW. Changing an array in-place is rare enough that special care is ok with me.

Rare in what?  Rare in what you're writing? I think you'll find that  many projects have use for it alot.

-Sha


August 02, 2005
>>> That is obsurd.  I would then need to check to
>>> see if it's given me back a reference to a new array before I could use
>>> it?
>>
>>why? The only time you would care is if you start modifying the array in-place.
>
> Exactly.  Quite often when I want to replace one thing, I want to replace
> ALOT
> of things. (Or take any
> other example.)  If each replace allocates a new string, that's
> inefficient.
> Maybe I only want to copy it
> once, and then modify it in place.   When .dup is only 4 extra characters
> per
> instance of this, it does not
> justify having two copies of every array function, one for cow and one for
> in
> place.

I don't know if you followed the recent COW/const/inplace performance discussion but my own $0.02 is that one should use COW as a general rule and after profiling the performance target a (presumably) small set of routines that need more careful memory management and possibly inplace manipulations. In a "worst case" one can use one of the many other memory management techniques listed in the D docs. In any case you might want to look over those recent COW threads for more (and more and more) discussion on the topic.

On a side note, remember that operations like "replace" might increase the length of the string (if the replacement is longer that the pattern) in which case modifying it inplace becomes tricky. A general rule like COW can take the place of lots of individual rules for each function. But you can code your app however you like or write a phobos lib that does everything inplace - there's nothing technically preventing that and it's perfectly ok if that's what you want to do.

>>> Also, Just because it is common
>>> doesn't make it logical, consistent, or obvious to a somebody not
>>> familiar
>>> with
>>> these __unwritten__ agreements.
>>
>>Unwritten in what sense? COW is documented in several places in D (though
>>I
>>would like even more documenation about it since it appears people don't
>>know about it).
>
> There's barely any documentation for the API as it is.   And a footnote
> about
> tolower( string ) on a man
> page is not enough for me.

I'm not sure what man page you are referring to since D doesn't have man pages (or footnotes from what I can tell). Maybe you are speaking figuratively in which case I recommend that if you have concrete suggestions for improving the doc that you add comments to the doc wiki.

On a slight OT I wonder if/how the doc wiki is being used. Are comments removed as they are fixed in the doc? what's the process for using the wiki? I add my comments where I think they should go but I notice there's stuff ranging all over the map and to be honest I have no clue if Walter ever looks at it, how often, and what happens when he does look at it.


August 02, 2005
In article <dcmpne$10pp$1@digitaldaemon.com>, Ben Hinkle says...
>
>>>> That is obsurd.  I would then need to check to
>>>> see if it's given me back a reference to a new array before I could use
>>>> it?
>>>
>>>why? The only time you would care is if you start modifying the array in-place.
>>
>> Exactly.  Quite often when I want to replace one thing, I want to replace
>> ALOT
>> of things. (Or take any
>> other example.)  If each replace allocates a new string, that's
>> inefficient.
>> Maybe I only want to copy it
>> once, and then modify it in place.   When .dup is only 4 extra characters
>> per
>> instance of this, it does not
>> justify having two copies of every array function, one for cow and one for
>> in
>> place.
>
>I don't know if you followed the recent COW/const/inplace performance discussion but my own $0.02 is that one should use COW as a general rule and after profiling the performance target a (presumably) small set of routines that need more careful memory management and possibly inplace manipulations. In a "worst case" one can use one of the many other memory management techniques listed in the D docs. In any case you might want to look over those recent COW threads for more (and more and more) discussion on the topic.

I think this would be a bad choice.  It might be wise with respect to
performance, but having different
methods randomly be cow or not cow depending on how much more time they take is
a bit confusing
to say the least.

>On a side note, remember that operations like "replace" might increase the length of the string (if the replacement is longer that the pattern) in which case modifying it inplace becomes tricky.

Inplace may not be possible, but it could still follow the normal rule of
modifying the ptr of your array
to point to the new value.  That way a dup only happens when it is required, and
the calling function
does not care.  This would be ideal IMHO.

> A general rule like COW can
>take the place of lots of individual rules for each function. But you can code your app however you like or write a phobos lib that does everything inplace - there's nothing technically preventing that and it's perfectly ok if that's what you want to do.

That's true, but it would be nice not to be including my own runtime in every
little application I write.  I
suppose I could force installation of a shared library.  Ugh.

>>>> Also, Just because it is common
>>>> doesn't make it logical, consistent, or obvious to a somebody not
>>>> familiar
>>>> with
>>>> these __unwritten__ agreements.
>>>
>>>Unwritten in what sense? COW is documented in several places in D (though
>>>I
>>>would like even more documenation about it since it appears people don't
>>>know about it).
>>
>> There's barely any documentation for the API as it is.   And a footnote
>> about
>> tolower( string ) on a man
>> page is not enough for me.
>
>I'm not sure what man page you are referring to since D doesn't have man pages (or footnotes from what I can tell). Maybe you are speaking figuratively in which case I recommend that if you have concrete suggestions for improving the doc that you add comments to the doc wiki.

Which I have been doing when I see them.  However, most of the doc that you can
post on the Wiki.  (I
haven't looked alot at it. ) Seems to be for the language specification.  Can
the phobos docs be
modified?

>
>On a slight OT I wonder if/how the doc wiki is being used. Are comments removed as they are fixed in the doc? what's the process for using the wiki? I add my comments where I think they should go but I notice there's stuff ranging all over the map and to be honest I have no clue if Walter ever looks at it, how often, and what happens when he does look at it.
>
>


August 02, 2005
>>> There's barely any documentation for the API as it is.   And a footnote about tolower( string ) on a man page is not enough for me.
>>
>>I'm not sure what man page you are referring to since D doesn't have man
>>pages (or footnotes from what I can tell). Maybe you are speaking
>>figuratively in which case I recommend that if you have concrete
>>suggestions
>>for improving the doc that you add comments to the doc wiki.
>
> Which I have been doing when I see them.  However, most of the doc that
> you can
> post on the Wiki.  (I
> haven't looked alot at it. ) Seems to be for the language specification.
> Can
> the phobos docs be  modified?

There's a link at the bottom of the phobos page for the wiki. I don't know if the modules with stand-along pages have the link, though.


1 2 3 4 5 6
Next ›   Last »