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

It's not just Sun!

http://www-306.ibm.com/software/globalization/icu/index.jsp
Compare the C++ version with the Java version.

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.

On Thu, 27 Jul 2006 18:39:29 -0600, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
> 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.

Sure. But are you trying to tell me that this..

String foo(String a) { .. return modified a .. }
String bar(String a) { .. return modified a .. }
String baz(String a) { .. return modified a .. }
String bob(String a) { .. return modified a .. }

String s = foo(bar(baz(bob("test"))));

Will result in _no_ needless copying?

Regan

Regan Heath wrote:
> On Thu, 27 Jul 2006 18:39:29 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
> 
>> 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.
> 
> 
> Sure. But are you trying to tell me that this..
> 
> String foo(String a) { .. return modified a .. }
> String bar(String a) { .. return modified a .. }
> String baz(String a) { .. return modified a .. }
> String bob(String a) { .. return modified a .. }
> 
> String s = foo(bar(baz(bob("test"))));
> 
> Will result in _no_ needless copying?
> 
> Regan

Same thing will happen will happen with phobos COW

P.S. Are you (or Reiner Pope) saying that Javari provides a better solution to this? <g>

On Thu, 27 Jul 2006 20:27:06 -0600, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
> Regan Heath wrote:
>> On Thu, 27 Jul 2006 18:39:29 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
>>
>>> 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.
>>   Sure. But are you trying to tell me that this..
>>  String foo(String a) { .. return modified a .. }
>> String bar(String a) { .. return modified a .. }
>> String baz(String a) { .. return modified a .. }
>> String bob(String a) { .. return modified a .. }
>>  String s = foo(bar(baz(bob("test"))));
>>  Will result in _no_ needless copying?
>>  Regan
>
> Same thing will happen will happen with phobos COW

At present. This is the 'problem' I'd like to solve somehow.

> P.S. Are you (or Reiner Pope) saying that Javari provides a better solution to this? <g>

No. I was just pointing out that Java's solution doesn't work for all cases.

The reason it doesn't work is that String and StringBuffer are seperate types. I think we need a single type (or 2 types which can be passed as an argument of the same name, perhaps 2 types where one is implicitly convertable to the other). Either way, we need to know whether we need to .dup or not.

Regan

Regan Heath wrote:
> On Thu, 27 Jul 2006 20:27:06 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
> 
>> Regan Heath wrote:
>>
>>> On Thu, 27 Jul 2006 18:39:29 -0600, Hasan Aljudy  <hasan.aljudy@gmail.com>  wrote:
>>>
>>>> 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.
>>>
>>>   Sure. But are you trying to tell me that this..
>>>  String foo(String a) { .. return modified a .. }
>>> String bar(String a) { .. return modified a .. }
>>> String baz(String a) { .. return modified a .. }
>>> String bob(String a) { .. return modified a .. }
>>>  String s = foo(bar(baz(bob("test"))));
>>>  Will result in _no_ needless copying?
>>>  Regan
>>
>>
>> Same thing will happen will happen with phobos COW
> 
> 
> At present. This is the 'problem' I'd like to solve somehow.
> 
>> P.S. Are you (or Reiner Pope) saying that Javari provides a better  solution to this? <g>
> 
> 
> No. I was just pointing out that Java's solution doesn't work for all  cases.
> 
> The reason it doesn't work is that String and StringBuffer are seperate  types. I think we need a single type (or 2 types which can be passed as an  argument of the same name, perhaps 2 types where one is implicitly  convertable to the other). Either way, we need to know whether we need to  .dup or not.
> 
> Regan

Well, for D, this can be solved with a non-COW versions of foo,baz, etc.

For Java, there is a possible solution that revolves around the same idea:

If a function is supposed to change the input string, and it's obvious (for example, if it's called toLower, toUpper .. etc), then it should take a StringBuffer, modify it in-place, and return it (as a StringBuffer).

If a String is passed, it can be implicitly converted to a StringBuffer (duplicated). (Ok, maybe this is not the current Java behaviour, but it's my porposed solution)
If a StringBuffer is passed, then it's all good.

This eliminates duplications in the given case. However, it creates a problem if the user expects a String return type:

StringBuffer foo(StringBuffer arg) { ... }

..
String a = "hi";
String b = foo(a);

this creates 2 duplicates: first duplicate a, then duplicate the returned string from foo.
(converting a StringBuffer to a String should create a duplicate, no?)

I'll make all my replies in this post.

Hasan Aljudy wrote:
> The biggest argument in favor of const has been that writing good libraries requires some constness guarantess.
I would rather say that the const checking makes writing libraries _easier_. The important thing about const is, as I said earlier, that it saves development time, because it avoids the need for code duplication. It is undeniable that all constness guarantees can be emulated by hand, but there is clearly a difference between what is needed and what is useful. Neither static typing nor unit testing add any efficiency to the actual code-/writing/ stage, but they save time on bug-hunting. A similar argument is true for const.

> However, as I see it, the only constness needed is one for arrays.
And it isn't even strictly *needed* for arrays, because one could create an array-wrapping pair of classes which emulate constness, as Java has indeed done for String (readonly form) and StringBuffer (read/write form). However, right in my first post which you still seem to have ignored, I outlined the trouble with this: duplicate code. An this is not theory, but practice, because code is indeed duplicated, as in Java's String and StringBuffer classes which are effectively two versions of the same thing: char[].

> 
> Java has immutable String class, thus it covers that area.
> As we all know, Java has one of the best libraries around.
We seem to be going round in circles because we disagree on the fundamentals. Your assertion: Java has one of the best libraries around. My assertion: it is not as good as all that, because of the unnecessary copying required. I am not saying that Javari fixes that problem (because it doesn't) but rather that looking to the knowledge there can provide some insight into avoiding that problem in D. As you may have seen from various other proposals for const in D, I have in fact found a way to avoid this duplication.

>>> P.S. Are you (or Reiner Pope) saying that Javari provides a better  solution to this? <g>
No, I'm not. I'm looking for a solution to this in D. If you look at some of my other posts, you'll see the solution.

Cheers,

Reiner

Hasan Aljudy wrote:
> 
> 
> Regan Heath wrote:
>> On Thu, 27 Jul 2006 20:27:06 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
>>
>>> Regan Heath wrote:
>>>
>>>> On Thu, 27 Jul 2006 18:39:29 -0600, Hasan Aljudy  <hasan.aljudy@gmail.com>  wrote:
>>>>
>>>>> 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.
>>>>
>>>>   Sure. But are you trying to tell me that this..
>>>>  String foo(String a) { .. return modified a .. }
>>>> String bar(String a) { .. return modified a .. }
>>>> String baz(String a) { .. return modified a .. }
>>>> String bob(String a) { .. return modified a .. }
>>>>  String s = foo(bar(baz(bob("test"))));
>>>>  Will result in _no_ needless copying?
>>>>  Regan
>>>
>>>
>>> Same thing will happen will happen with phobos COW
>>
>>
>> At present. This is the 'problem' I'd like to solve somehow.
>>
>>> P.S. Are you (or Reiner Pope) saying that Javari provides a better  solution to this? <g>
>>
>>
>> No. I was just pointing out that Java's solution doesn't work for all  cases.
>>
>> The reason it doesn't work is that String and StringBuffer are seperate  types. I think we need a single type (or 2 types which can be passed as an  argument of the same name, perhaps 2 types where one is implicitly  convertable to the other). Either way, we need to know whether we need to  .dup or not.
>>
>> Regan
> 
> Well, for D, this can be solved with a non-COW versions of foo,baz, etc.
> 
> For Java, there is a possible solution that revolves around the same idea:
> 
> If a function is supposed to change the input string, and it's obvious (for example, if it's called toLower, toUpper .. etc), then it should take a StringBuffer, modify it in-place, and return it (as a StringBuffer).
> 
> If a String is passed, it can be implicitly converted to a StringBuffer (duplicated). (Ok, maybe this is not the current Java behaviour, but it's my porposed solution)
> If a StringBuffer is passed, then it's all good.
> 
> This eliminates duplications in the given case. However, it creates a problem if the user expects a String return type:
> 
> StringBuffer foo(StringBuffer arg) { ... }
> 
> ..
> String a = "hi";
> String b = foo(a);
> 
> this creates 2 duplicates: first duplicate a, then duplicate the returned string from foo.
> (converting a StringBuffer to a String should create a duplicate, no?)
> 
> 

The classes String and StringBuffer implements CharSequence, so declaring a function to recieve a CharSequence can handle both scenarios. If the function modifies the "string", it can create a String Buffer from it and return it as a CharSquence.

CharSquence foo(CharSequence arg) { ... }

Ary

Ary Manzana wrote:
> Hasan Aljudy wrote:
> 
>>
>>
>> Regan Heath wrote:
>>
>>> On Thu, 27 Jul 2006 20:27:06 -0600, Hasan Aljudy <hasan.aljudy@gmail.com>  wrote:
>>>
>>>> Regan Heath wrote:
>>>>
>>>>> On Thu, 27 Jul 2006 18:39:29 -0600, Hasan Aljudy  <hasan.aljudy@gmail.com>  wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>>   Sure. But are you trying to tell me that this..
>>>>>  String foo(String a) { .. return modified a .. }
>>>>> String bar(String a) { .. return modified a .. }
>>>>> String baz(String a) { .. return modified a .. }
>>>>> String bob(String a) { .. return modified a .. }
>>>>>  String s = foo(bar(baz(bob("test"))));
>>>>>  Will result in _no_ needless copying?
>>>>>  Regan
>>>>
>>>>
>>>>
>>>> Same thing will happen will happen with phobos COW
>>>
>>>
>>>
>>> At present. This is the 'problem' I'd like to solve somehow.
>>>
>>>> P.S. Are you (or Reiner Pope) saying that Javari provides a better  solution to this? <g>
>>>
>>>
>>>
>>> No. I was just pointing out that Java's solution doesn't work for all  cases.
>>>
>>> The reason it doesn't work is that String and StringBuffer are seperate  types. I think we need a single type (or 2 types which can be passed as an  argument of the same name, perhaps 2 types where one is implicitly  convertable to the other). Either way, we need to know whether we need to  .dup or not.
>>>
>>> Regan
>>
>>
>> Well, for D, this can be solved with a non-COW versions of foo,baz, etc.
>>
>> For Java, there is a possible solution that revolves around the same idea:
>>
>> If a function is supposed to change the input string, and it's obvious (for example, if it's called toLower, toUpper .. etc), then it should take a StringBuffer, modify it in-place, and return it (as a StringBuffer).
>>
>> If a String is passed, it can be implicitly converted to a StringBuffer (duplicated). (Ok, maybe this is not the current Java behaviour, but it's my porposed solution)
>> If a StringBuffer is passed, then it's all good.
>>
>> This eliminates duplications in the given case. However, it creates a problem if the user expects a String return type:
>>
>> StringBuffer foo(StringBuffer arg) { ... }
>>
>> ..
>> String a = "hi";
>> String b = foo(a);
>>
>> this creates 2 duplicates: first duplicate a, then duplicate the returned string from foo.
>> (converting a StringBuffer to a String should create a duplicate, no?)
>>
>>
> 
> The classes String and StringBuffer implements CharSequence, so declaring a function to recieve a CharSequence can handle both scenarios. If the function modifies the "string", it can create a String Buffer from it and return it as a CharSquence.
> 
> CharSquence foo(CharSequence arg) { ... }
> 
> Ary

Ah, yes. I forgot about CharSequence and interfaces! :D

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