On Sat, 25 Apr 2009 20:17:00 -0400, Unknown W. Brackets
<unkn...@simplemachines.org> wrote:
Let me say it a different way:
split() returns results that are, often, stored or compared. It is not
often that these results are concatenated to or modified. Possibly,
they may not be sliced (further) often either.
Such a case represents a perfect example of an array (or string) that
need not have a greater capacity than its length. Indeed; no property
of the array is likely to change - its length, contents, capacity, or
even ptr. All are likely to remain constant until the object is deleted
from memory.
So, it would seem to me, this return value (as a quick example) could
easily be changed to one that fits the following:
1. Is an array of data.
2. Does not have mutable contents (data.)
3. Does not allow its length or capacity to be extended (excuse me for
considering this mutation.)
4. Is a reference, rather than a static array.
My suggestion is that "char[]" should _be_ a StringBuilder, and "int[]"
should _be_ an ArrayBuilder, and we should adopt a separate syntax for
something that _isn't_ one of those.
That said, I did just browse some of my D source files - an XML 1.0
parser/tree and a custom rfc-compliant ftp server - and nearly the only
concatenation I use is building exception strings. I'm a little
surprised. Only a couple times do I do anything a builder would be
useful for.
One time is on XML child nodes; since I'm building a list of children,
it is a "builder" type thing. However, my XML tree is fully incremental
- that means you could traverse it before all of the data has been read
from the net. It would not be practical for me to use a builder that
didn't have proper read access for this case.
I really think using a "StringBuilder" class is just like the solution
of using a "String" class. D, in my opinion, proved the latter was not
necessary; I hold that the former isn't either.
-[Unknown]
Okay, I understand where you're coming from. Here are some counter-points
1) Immutable strings are often concatenated, which you don't address
2) int[], real[], and basically anything not a string rarely concatenates,
but often mutable, which you don't address
3) Rather large thread a while ago concluded the builder overhead was too
high for general use.
4) You're proposal makes immutable char[] and char[] have different
underlying representations.
