I favour (insist on) names linked closely to the type being worked on, rather than creating new names. Basically, its not the job/role of [lang] to create new concepts, just to simplify working with existing concepts IMO. (see the lang proposal.html and status.html)
Stephen > And what do people think here of introducing a different term (say Strand) > for this concept as I discussed earlier (I paste that here, last time it was > buried under confusion due to a typo.) > > " > Talking about name, I would add my opinion that while it might be > nice to have a name for the replacer that is much like the replacee, > (StringBuf) one might prefer a more descriptive name at the expense > of this convenience: (*** MutableString). > > As a compromise between the two, the name Strand can be adopted (Str... > thus near the original one + can be defined to represent a mutable > string contrasted with "String" which, by virtue of the so-named > class in the API, is immutable.) > " > > Ash > > > > --------------------------------------------- > > Run, rabbit run. > Dig that hole, forget the sun, > And when at last the work is done > Don't sit down it's time to dig another one. > > _________________________________________________________________ > Our best dial-up offer is back. Get MSN Dial-up Internet Service for 6 > months @ $9.95/month now! http://join.msn.com/?page=dept/dialup > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
