Javari's Reference Immutability

[Bruno Medeiros]

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

I doubt anyone has said exactly that. First, const/immutability is not 
strictly "required", but it helps or improves the quality of a library.
Second, it is not just for libraries, it is for any kind of code.
Third, what is a "good" library depends on the language. Many things are 
good and acceptable for Java, but are not for D. (see below)

Also, going back to the second point, the kind of code that a 
const/immutability mechanism helps particularly more is domain logic 
code, or better said: code which handles domain objects (or abstract 
data types).
A library, particularly a system/language library has little domain 
objects (or ADTs) and as such, for many parts of the library it will 
make little difference whether a const mechanism exists or not. For 
example, a Thread, Stream, File, etc. classes are not "domain" types, 
rather they are "handle" types which manage a resource which exists 
outside of the data the class itself holds. There is not much sense for 
there to be readonly views of these objects as they are not changed in 
the same way "domain" types are.
Now what are the "domain" types in Java's lib? It's String (and it's 
corresponding StringBuffer), and also List and the whole Collection 
classes, and maybe some more I don't recall or know right now.
These types have all some sort of const/immutability mechanism since 
such mechanism is very important (in the case of Java, a custom, 
"user"-made one, not natural to the language).
In the case of String, you have two classes for each const/nonconst 
version. In the case of a List or other Collections such attribute is 
part of the object state, and a check is made at runtime. Here's an 
example of usage of a const and a non-const Collection:

   List<Object> lst = new ArrayList<Object>();
   List<Object> lst2 = Collections.unmodifiableList(lst);
		
   lst.add("ddd");
   lst2.add("ddd"); // Runtime error: UnsupportedOperationException

The first point pro a const/immutability mechanism (as a language 
construct) is that it saves work of creating the const mechanism on a 
custom, per user class basis. (if you're just using a code/library 
already done, it won't matter, but it doesn't invalidate the point)

The second point pro a const/immutability mechanism (as a language 
construct), especially if it as compile time one, is that of efficiency. 
  Those custom, user-made mechanisms are all slower than a compile time 
one, since they require extra duping of objects, and/or runtime 
constness data and checks.
Of course one can /not/ implement these custom mechanism at all, but 
then you are less safe from ownership violations.

For more info see the "2. Motivation" section in the Javari paper.

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

What is good, best, acceptable, etc. for one language may not be for 
another language. Java's solution (COW) is acceptable for Java because 
Java is not meant to be fast, but it is not acceptable/good for D.
Note: when I say COW is acceptable for Java, I mean for small types like 
strings, or a Collection proxy, etc, because for large, complex types, 
even for Java it will burdensome to duplicate indiscriminately.

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

Reiner is right, dismissing points like that is lame and foolish.

Plus, your request for examples ("Show me real life examples that prove 
Javari to be superior to Java") is flawed.
First Javari is *very* recent (from years 2004-2005), and is an 
"academic", proof-of-concept language, so it is not in mainstream use 
and maybe not meant for it.
Second, the lack of a const mechanism is not as harmful to Java as it 
for a language of the likes of D, for the reasons explained above. So 
you if want an example, it should be one of the same kind as D, so will 
give quite a good one:
C++

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D