Javari's Reference Immutability
hasan.aljudy at gmail.com
Tue Jul 25 18:10:51 PDT 2006
Regan Heath wrote:
> But java has immutable strings, right?
> That in itself is a form of 'const' covering the most common use cases.
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?
> 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:
>>> 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?
More information about the Digitalmars-d-learn