Javari's Reference Immutability

[Hasan Aljudy]

Ary Manzana wrote:
> Hasan Aljudy wrote:
> 
>>
>>
>> Regan Heath wrote:
>>
>>> On Thu, 27 Jul 2006 20:27:06 -0600, Hasan Aljudy 
>>> <hasan.aljudy at gmail.com>  wrote:
>>>
>>>> Regan Heath wrote:
>>>>
>>>>> On Thu, 27 Jul 2006 18:39:29 -0600, Hasan Aljudy  
>>>>> <hasan.aljudy at gmail.com>  wrote:
>>>>>
>>>>>> You say that Java's String class implies alot of copying, 
>>>>>> therefor  it's  bad. However, you fail to realize that copying 
>>>>>> when modifying is  exactly  what COW stands for. COW is a kind of 
>>>>>> honor-system protocol  implemented  by phobos. Everytime phobos 
>>>>>> thinks it needs to modify a  string which it  doesn't own, it 
>>>>>> makes a copy first to keep the  original string intact.  In Java, 
>>>>>> this can be done by creating a  StringBuffer from the String  
>>>>>> (which creates a copy), after that, any  modification you make to  
>>>>>> StringBuffer happens in-place; no needless  copying.
>>>>>
>>>>>
>>>>>   Sure. But are you trying to tell me that this..
>>>>>  String foo(String a) { .. return modified a .. }
>>>>> String bar(String a) { .. return modified a .. }
>>>>> String baz(String a) { .. return modified a .. }
>>>>> String bob(String a) { .. return modified a .. }
>>>>>  String s = foo(bar(baz(bob("test"))));
>>>>>  Will result in _no_ needless copying?
>>>>>  Regan
>>>>
>>>>
>>>>
>>>> Same thing will happen will happen with phobos COW
>>>
>>>
>>>
>>> At present. This is the 'problem' I'd like to solve somehow.
>>>
>>>> P.S. Are you (or Reiner Pope) saying that Javari provides a better  
>>>> solution to this? <g>
>>>
>>>
>>>
>>> No. I was just pointing out that Java's solution doesn't work for 
>>> all  cases.
>>>
>>> The reason it doesn't work is that String and StringBuffer are 
>>> seperate  types. I think we need a single type (or 2 types which can 
>>> be passed as an  argument of the same name, perhaps 2 types where one 
>>> is implicitly  convertable to the other). Either way, we need to know 
>>> whether we need to  .dup or not.
>>>
>>> Regan
>>
>>
>> Well, for D, this can be solved with a non-COW versions of foo,baz, etc.
>>
>> For Java, there is a possible solution that revolves around the same 
>> idea:
>>
>> If a function is supposed to change the input string, and it's obvious 
>> (for example, if it's called toLower, toUpper .. etc), then it should 
>> take a StringBuffer, modify it in-place, and return it (as a 
>> StringBuffer).
>>
>> If a String is passed, it can be implicitly converted to a 
>> StringBuffer (duplicated). (Ok, maybe this is not the current Java 
>> behaviour, but it's my porposed solution)
>> If a StringBuffer is passed, then it's all good.
>>
>> This eliminates duplications in the given case. However, it creates a 
>> problem if the user expects a String return type:
>>
>> StringBuffer foo(StringBuffer arg) { ... }
>>
>> ..
>> String a = "hi";
>> String b = foo(a);
>>
>> this creates 2 duplicates: first duplicate a, then duplicate the 
>> returned string from foo.
>> (converting a StringBuffer to a String should create a duplicate, no?)
>>
>>
> 
> The classes String and StringBuffer implements CharSequence, so 
> declaring a function to recieve a CharSequence can handle both 
> scenarios. If the function modifies the "string", it can create a String 
> Buffer from it and return it as a CharSquence.
> 
> CharSquence foo(CharSequence arg) { ... }
> 
> Ary

Ah, yes. I forgot about CharSequence and interfaces! :D