# Object Design question.

- Thread: https://externals.io/message/1150
- Original archive: https://news-web.php.net/php.internals/1150
- Started by l0t3k on 2003-05-01T13:02:07+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #1150 — l0t3k — 2003-05-01T13:02:07+00:00

URL: https://externals.io/message/1150#1150

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.

  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.

l0t3k

---

## #1158 — marcus.boerger@t-online.de — 2003-05-02T10:56:53+00:00

URL: https://externals.io/message/1150#1158 · In reply to: #1150

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