Javari's Reference Immutability

[Regan Heath]

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.

Regan

On Wed, 26 Jul 2006 12:40:54 +1200, Regan Heath <regan at netwin.co.nz> 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.
>
> 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
>