At 15:02 01.05.2003, l0t3k wrote:
>im writing a UnicodeString class for an extension and wanted to ask a
>question related to the design of the user-space API.
>
>the issue is with operations that perform modifications (insert, remove,
>padding, etc). we have the java/javascript route where strings are
>immutable, meaning that each modification operation creates a new string
>while leaving the original unmodified. this has the virtue of being familar
>to people (less WTF), though its less efficient. but we may also choose to
>do modifications in-place and return a reference to the string.
Java is the full WTF overkill-megabloat when it comes to think about
memory usage. So please don't do the same mistake!
> i copped out for now and provided for having modification methods function
>statically as well as non-statically. f. ex.
>
>// modifies $warAndPeace. $str and $warAndPeace refer to the same string
>(1) $str = I18N::UnicodeString::insert($warAndPeace, $editorsNotes, 0);
>
>// creates $newString, copies $warAndPeace to it, and does the insert
>(2) $newString = $warAndPeace->insert($editorsNotes, 0)
>
>the question is should (2) return a reference to the original which is
>modified in place. i think having static/non-static handling may be the way
>out, but the concern there is perceived bloatage.
static = copy
dynamic = inplace