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