Javari's Reference Immutability

[Hasan Aljudy]

Reiner Pope wrote:
> 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?

Calm down please.
I'm not saying const is totally useless (not that I use or need it anyway).

The biggest argument in favor of const has been that writing good 
libraries requires some constness guarantess.
However, as I see it, the only constness needed is one for arrays.

Java has immutable String class, thus it covers that area.
As we all know, Java has one of the best libraries around.

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.


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

Well it's your call.
Right now, I think Javari is a useless extension.