Javari's Reference Immutability

[Hasan Aljudy]

Regan Heath wrote:
> But java has immutable strings, right?
> http://www.janeg.ca/scjp/pkglang/immutable.html
> 
> That in itself is a form of 'const' covering the most common use cases.

I know.
I was commenting on const objects, not arrays. What's the point of Javari?

 > Of course, because the string is immutable if you modify it, you
 > actually  modify a duplicate string. Are they reference counted then? or
 > does it dup  on every single modification? If so, this would be a very
 > inefficient  implementation of COW.

No, in Java, you can't modify a string. It's a read only reference <g>.
You can modify a StringBuffer in place. However, with String, you can 
only change what the reference refers to.

String concatenation creates a new string:
# String x = a + b;
Here, (assuming a and b are both, String objects) a new string is 
created. The original a and b are not changed.

I think that's the same with array concatenation in D, no?

> 
> Regan
> 
> On Tue, 25 Jul 2006 18:21:58 -0600, Hasan Aljudy 
> <hasan.aljudy at gmail.com>  wrote:
> 
>> I think the question is: what's the point?
>> Clearly, Java's lack of const didn't prevent it from the having some 
>> of  the best libraries there are.
>>
>> Reiner Pope wrote:
>>
>>> I've read the paper on Javari's reference immutability (thanks to  
>>> Bruno) and it has an interesting idea: a synthesis of dynamic and  
>>> static checking.  This makes it easier to interface const-aware code  
>>> with const-unaware code. It can be demonstrated as follows:
>>>  Date a = new Date(); // a mutable date
>>> readonly Date b = a; // A readonly view of a
>>> Date c = (mutable) b; // The compiler bypass static checking, but  
>>> inserts dynamic checks.
>>> a.modify(); // OK
>>> b.modify(); // Compile-time error
>>> c.modify(); // Runtime error
>>>   How could you implement the runtime checking? A first thought 
>>> would  be to add the following assert to the in contract of every 
>>> mutating  method:
>>>    assert(!isConst);
>>>  But that requires that the /class/ knows the const-ness of the  
>>> reference it is accessed through, which I don't think it does.
>>>  The other alternative seems to be a much easier one: simply modify 
>>> the  vtbl so that all mutating functions point to a single line:
>>>    assert(false, "Trying to modify a class through a readonly view");
>>>  The problem with that is that I suspect the vtable is stored with 
>>> the  class, not the reference, so modifying the vtable will modify it 
>>> for  all other references, even if they aren't readonly.
>>>  Clearly, Javari manages such checking, and it claims to manage it in 
>>> a  Java-compatible (backwards-compatible) way. How is it done in 
>>> Javari,  and how could it be done in D?
>>>   Cheers,
>>>  Reiner
> 
>