If T[new] is the container for T[], then what is the container for T[U]?

[Unknown W. Brackets]

(and I know I said "char[] should _be_ a StringBuilder", which probably 
caused the confusion - sorry.  I was trying to differentiate the two, I 
worded it poorly for what I actually meant.)

-[Unknown]


Unknown W. Brackets wrote:
> 1. Well, I think that immutable(T[]) ~ immutable(T[]) should be 
> possible.  I thought it was.  Just that you cannot _append_ to 
> immutable(T[]) which completely makes sense.
> 
> 2. I don't know that it rarely concatenates.  I took Calc, but I am not 
> a mathematician... mostly I use char and object references in my arrays. 
>  Occasionally int[], and maybe real[] but it's not likely.
> 
> So, yes, I probably am not properly addressing this.  Frankly I do not 
> know the use-cases where you would mutate such an array.
> 
> For objects, if you don't change the array length, it's unlikely you'll 
> change its contents (pointers.)  Unfortunately, the referenced object 
> would need to be mutable in many cases (although this is probably less 
> than one would think offhand for the case of arrays of 
> already-initialized objects.)
> 
> 3. Okay.  I think for a multi-purpose builder, that's true.  However, 
> speaking only of having an extended capacity (as is currently and as I 
> was quoting), and not other features of a builder, I think what I say 
> does make sense.
> 
> 4. I don't think so.  Again, I'm not talking about a full-fledged 
> builder (although I think more features of one would be possible without 
> too much difference except fake methods), just about features.
> 
> So, to recap, I'm really talking about not over-allocating immutable 
> arrays, but I'm not talking about changing current arrays.  Does that 
> make my comments make more sense?
> 
> -[Unknown]
> 
> 
> Robert Jacques wrote:
>> On Sat, 25 Apr 2009 20:17:00 -0400, Unknown W. Brackets 
>> <unknown at 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.