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

Reiner Pope wrote:

> 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.

That problem is easy to solve:
Just have 2 vtables per class - one for mutable instances and one for readonly.

Cast to readonly will involve changing vtable ptr in the instance then.


-- 

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

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@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

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@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@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
>

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@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
> 
> 

Hasan Aljudy 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.
> 

However, it is one of the reasons that Java is so slow. Instead of a proper implementation of reference immutability, anything that needs to be kept constant is either written as a readonly interface, or is simply duplicated. This means either code duplication or data duplication; the former leads to more bugs as everyone knows, and the latter leads to worse speeds. Although lack of speed due to duplication could be seen by some as acceptable, because (a) Java isn't meant for speed and (b) the error-catching achieved by duplication is more important than the speed of not, these arguments are clearly weak, and (more importantly) completely inapplicable for D. Effectively, Java *does* have a const mechanism, just a slow and painful one, because it must be enforced by the coder, not the compiler, and it is slow because it requires duplication.

Just because Java manages to have good libraries it doesn't mean ignoring const is the best solution. Remember also that there is a huge company behind Java, so they can afford the extra time required in testing and documenting their libraries by hand for const violations. However, in D, this is not the case, and even if there were such a company, it would be worse for the individuals, who would have trouble competing with the error-checking resources of the company.

The benefits of const are:
 - Machine checking of code, leading to higher-level code (eg 'in', 'out' and 'inout' are much more informative than 'this parameter is a class so it can be modified', 'this parameter is a struct so it won't be modified', etc.)
 - Saving either developer time or running time. Since most people can't be bothered to spend the time checking for const-violations by hand, they will tend to create const-safety through duplicates. If they are truly masochistic, then they can ensure by hand that it is safe, but this is unreliable, and requires extra work.
 - If the const mechanism is trustworthy, other optimizations could be explored, such as those possible in functional languages due to the lack of side effects (ie, everything being const): in a functional language,

  a = sin(1);
  b = sin(1);

would only evaluate sin(1) once, and cache the answer. In D, however, it would be calculated twice, slowing it down. For any argument that this could be optimized away by a Sufficiently Smart Compiler, you can make arbitrarily hard optimizations that const would fix but the compiler would not.

Cheers,

Reiner

Reiner Pope wrote:
> Hasan Aljudy 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.
>>
> 
> However, it is one of the reasons that Java is so slow. Instead of a proper implementation of reference immutability, anything that needs to be kept constant is either written as a readonly interface, or is simply duplicated. This means either code duplication or data duplication; the former leads to more bugs as everyone knows, and the latter leads to worse speeds. Although lack of speed due to duplication could be seen by some as acceptable, because (a) Java isn't meant for speed and (b) the error-catching achieved by duplication is more important than the speed of not, these arguments are clearly weak, and (more importantly) completely inapplicable for D. Effectively, Java *does* have a const mechanism, just a slow and painful one, because it must be enforced by the coder, not the compiler, and it is slow because it requires duplication.

Actually java provides a StringBuffer which can eliminate most of the unnecessary string duplication when one needs to modify a string.

> 
> Just because Java manages to have good libraries it doesn't mean ignoring const is the best solution. Remember also that there is a huge company behind Java, so they can afford the extra time required in testing and documenting their libraries by hand for const violations. However, in D, this is not the case, and even if there were such a company, it would be worse for the individuals, who would have trouble competing with the error-checking resources of the company.

There are alot of third-party libraries for Java, and they're still very good. I mean, compare any library that has a version for C++ and a version for Java; I bet you the Java version will always be much much better. ICU is a good example of this, I think.


> 
> The benefits of const are:
<sbip>
> 

No no .. don't give me theory.
Tell me what's the point of const in Javari.
Show me real life examples that prove Javari to be superior to Java.


> Cheers,
> 
> Reiner

Hasan Aljudy 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.

This doesn't mean Java is superb as a language. It means that Sun just invested tons of money in writing Java libraries with lots of features.

-- 

Hasan Aljudy wrote:
> 
> 
> Reiner Pope wrote:
>> Hasan Aljudy 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.
>>>
>>
>> However, it is one of the reasons that Java is so slow. Instead of a proper implementation of reference immutability, anything that needs to be kept constant is either written as a readonly interface, or is simply duplicated. This means either code duplication or data duplication; the former leads to more bugs as everyone knows, and the latter leads to worse speeds. Although lack of speed due to duplication could be seen by some as acceptable, because (a) Java isn't meant for speed and (b) the error-catching achieved by duplication is more important than the speed of not, these arguments are clearly weak, and (more importantly) completely inapplicable for D. Effectively, Java *does* have a const mechanism, just a slow and painful one, because it must be enforced by the coder, not the compiler, and it is slow because it requires duplication.
> 
> Actually java provides a StringBuffer which can eliminate most of the unnecessary string duplication when one needs to modify a string.
> 
So what if it does? You say that const-checking is obviously not important because Java doesn't have it. I then rebutted that by explaining the various evils of the Java library: it has pseudo const checking which is slow (ie immutable strings). Your example, StringBuffer, is actually a case for my side: it allows unprotected access, yet it isn't used anywhere near as much as the immutable version: java.lang.String. Can you tell me why, if const-ness is so useless?

>>
>> Just because Java manages to have good libraries it doesn't mean ignoring const is the best solution. Remember also that there is a huge company behind Java, so they can afford the extra time required in testing and documenting their libraries by hand for const violations. However, in D, this is not the case, and even if there were such a company, it would be worse for the individuals, who would have trouble competing with the error-checking resources of the company.
> 
> There are alot of third-party libraries for Java, and they're still very good. I mean, compare any library that has a version for C++ and a version for Java; I bet you the Java version will always be much much better. ICU is a good example of this, I think.
> 
> 
>>
>> The benefits of const are:
> <sbip>
>>
> 
> No no .. don't give me theory.
> Tell me what's the point of const in Javari.
> Show me real life examples that prove Javari to be superior to Java.
> 
> 
I'm not going to argue with someone who dismisses what I say so casually.

Cheers,

Reiner