Javari's Reference Immutability

Reiner Pope reiner.pope at gmail.com
Thu Jul 27 13:02:22 PDT 2006


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



More information about the Digitalmars-d-learn mailing list