Hello,When you create an array of numbers, like int array[]=new int[1000]; what is the initial value of the array? Are all the members set to zero, or is it undetermined?Thanks 

Ouabaine wrote:> Hello,> > When you create an array of numbers, like int array[]=new int[1000]; what is > the initial value of the array? Are all the members set to zero, or is it > undetermined?<http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.3>> An array initializer creates an array and provides initial values for all its components.<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.10.1>> Then, if a single DimExpr appears, a single-dimensional > array is created of the specified length, and each component of the > array is initialized to its default value (§4.12.5).-- Lew

Lew <lew@lewscanon.com> wrote:> Ouabaine wrote:> > Hello,> >> > When you create an array of numbers, like int array[]=new int[1000];> > what is the initial value of the array? Are all the members set to> > zero, or is it undetermined?>> <http://java.sun.com/docs/books/jls/third_edition/html/arrays.html#10.3>> > An array initializer creates an array and provides initial values for> > all its components.>> <http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#1> 5.10.1>> > Then, if a single DimExpr appears, a single-dimensional> > array is created of the specified length, and each component of the> > array is initialized to its default value (§4.12.5).And the most interesting link which is:4.12.5 Initial Values of Variableshttp://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#96595Numbers are set to zero as the default value, boolean is set to false, andreference variables are set to null.-- Curt Welch                                            http://CurtWelch.Com/curt@kcwc.com                                        http://NewsReader.Com/

Ouabaine wrote:>>> When you create an array of numbers, like int array[]=new int[1000];>>> what is the initial value of the array? Are all the members set to>>> zero, or is it undetermined?Lew wrote:>>> array is initialized to its default value (§4.12.5).                                                 ^^^^^^Curt Welch wrote:> 4.12.5 Initial Values of Variables> > http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#9659> 5> > Numbers are set to zero as the default value, boolean is set to false, and> reference variables are set to null.This section applies to more than just arrays.-- Lew

On Nov 29, 2:16 am, "Ouabaine" <ouaba...@orange.fr> wrote:> Hello,>> When you create an array of numbers, like int array[]=new int[1000]; what is> the initial value of the array? Are all the members set to zero, or is it> undetermined?>> ThanksJust as an aside, Java provides a Collections framework which hasextensive support for array-type work but is generally faster/easierto use/etc.  It's not always right or feasible to use Collections, butI just wanted to point them out in case you are learning Java anddidn't know about them.http://java.sun.com/docs/books/tutorial/collections/index.html

Jason Cavett wrote:> On Nov 29, 2:16 am, "Ouabaine" <ouaba...@orange.fr> wrote:>> Hello,>>>> When you create an array of numbers, like int array[]=new int[1000]; what is>> the initial value of the array? Are all the members set to zero, or is it>> undetermined?>>>> Thanks> > Just as an aside, Java provides a Collections framework which has> extensive support for array-type work but is generally faster/easier> to use/etc.  It's not always right or feasible to use Collections, but> I just wanted to point them out in case you are learning Java and> didn't know about them.> > http://java.sun.com/docs/books/tutorial/collections/index.htmlA further aside.While "it's not always right or feasible to use Collections" should bephrased "In a few very specific circumstances you would choose Arrays ofCollections".Using arrays in preference to collections is a form a primitive obsession.<http://virtualinfinity.net/wordpress/program-design/2007/10/28/primitive-obsession/>If you have a performance critical application *and a profiler tells youthat using collections is a bottleneck*, then you should *consider*using arrays.  Even before considering arrays, consider alternativeimplementations of the Collection types your using (LinkedList VsArrayList, HashSet vs TreeSet, etc...).The only other time you should consider using Arrays is interfacing tolegacy code which doesn't have collections support.  Even in that case,its usually better to use a collection and then peform a toArray() callwhen passing to the legacy code, and java.util.Arrays.asList() whenreceiving from the legacy code.-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:> Jason Cavett wrote:> >> On Nov 29, 2:16 am, "Ouabaine" <ouaba...@orange.fr> wrote:>>>>> Hello,>>>>>> When you create an array of numbers, like int array[]=new int[1000]; >>> what is>>> the initial value of the array? Are all the members set to zero, or >>> is it>>> undetermined?>>>>>> Thanks>>>>>> Just as an aside, Java provides a Collections framework which has>> extensive support for array-type work but is generally faster/easier>> to use/etc.  It's not always right or feasible to use Collections, but>> I just wanted to point them out in case you are learning Java and>> didn't know about them.>>>> http://java.sun.com/docs/books/tutorial/collections/index.html> > A further aside.> While "it's not always right or feasible to use Collections" should be> phrased "In a few very specific circumstances you would choose Arrays of> Collections".> > Using arrays in preference to collections is a form a primitive obsession.> > <http://virtualinfinity.net/wordpress/program-design/2007/10/28/primitive-obsession/> > > > If you have a performance critical application *and a profiler tells you> that using collections is a bottleneck*, then you should *consider*> using arrays.  Even before considering arrays, consider alternative> implementations of the Collection types your using (LinkedList Vs> ArrayList, HashSet vs TreeSet, etc...).I often choose arrays in preference to collections because of the betternotation for accessing and changing elements. Much more to do with codeclarity than with performance.Patricia

Patricia Shanahan wrote:> Daniel Pitts wrote:>> Jason Cavett wrote:>>>>> On Nov 29, 2:16 am, "Ouabaine" <ouaba...@orange.fr> wrote:>>>>>>> Hello,>>>>>>>> When you create an array of numbers, like int array[]=new int[1000]; >>>> what is>>>> the initial value of the array? Are all the members set to zero, or >>>> is it>>>> undetermined?>>>>>>>> Thanks>>>>>>>>> Just as an aside, Java provides a Collections framework which has>>> extensive support for array-type work but is generally faster/easier>>> to use/etc.  It's not always right or feasible to use Collections, but>>> I just wanted to point them out in case you are learning Java and>>> didn't know about them.>>>>>> http://java.sun.com/docs/books/tutorial/collections/index.html>>>> A further aside.>> While "it's not always right or feasible to use Collections" should be>> phrased "In a few very specific circumstances you would choose Arrays of>> Collections".>>>> Using arrays in preference to collections is a form a primitive >> obsession.>>>> <http://virtualinfinity.net/wordpress/program-design/2007/10/28/primitive-obsession/> >>>>>> If you have a performance critical application *and a profiler tells you>> that using collections is a bottleneck*, then you should *consider*>> using arrays.  Even before considering arrays, consider alternative>> implementations of the Collection types your using (LinkedList Vs>> ArrayList, HashSet vs TreeSet, etc...).> > I often choose arrays in preference to collections because of the better> notation for accessing and changing elements. Much more to do with code> clarity than with performance.> > PatriciaAlas, if only Java supported proper operator overloading :-/Code clarity for a fixed sized collection *maybe*.  I still usually go with collections. foo[1] isn't so concise that I fill bad about using foo.get(1);-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:> Patricia Shanahan wrote:....>> I often choose arrays in preference to collections because of the better>> notation for accessing and changing elements. Much more to do with code>> clarity than with performance.>>>> Patricia> > Alas, if only Java supported proper operator overloading :-/> > Code clarity for a fixed sized collection *maybe*.  I still usually go > with collections. foo[1] isn't so concise that I fill bad about using > foo.get(1);> Indeed. There *should* be a single concise syntax for indexed access toany integer-indexed Collection, and a reference array should just be aspecial case of ArrayList in which the exact size is known at the timeof construction. That would leave primitive arrays as a performanceoptimization.I don't think the interesting case is a single reference. Here's asimple example:out[i][j] += in1[i][k] * in2[k][j];Patricia

Patricia Shanahan wrote:> Daniel Pitts wrote:>> Patricia Shanahan wrote:> ....>>> I often choose arrays in preference to collections because of the better>>> notation for accessing and changing elements. Much more to do with code>>> clarity than with performance.>>>>>> Patricia>>>> Alas, if only Java supported proper operator overloading :-/>>>> Code clarity for a fixed sized collection *maybe*.  I still usually go >> with collections. foo[1] isn't so concise that I fill bad about using >> foo.get(1);>>> > Indeed. There *should* be a single concise syntax for indexed access to> any integer-indexed Collection, and a reference array should just be a> special case of ArrayList in which the exact size is known at the time> of construction. That would leave primitive arrays as a performance> optimization.> > I don't think the interesting case is a single reference. Here's a> simple example:> > out[i][j] += in1[i][k] * in2[k][j];> > Patricia> > Why limit yourself to integer indexed types? Maps could make use of the [] syntax as well:foo["Bar"] = "Bob";If I were to implement it, there would be two methods to override, since Java doesn't support references the same way C++ does:operator[](index); and operator[]=(index, value);Of course, allowing the override of other arithmetic operations would be useful as well.In my opinion, if you can do it to a primitive, you should be able to do it to a primitive wrapper.-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:> Patricia Shanahan wrote:>> I often choose arrays in preference to collections because of the better>> notation for accessing and changing elements. Much more to do with code>> clarity than with performance.>> Alas, if only Java supported proper operator overloading :-/The two instances in which I can support operator overloading:1. Bracketed access for Collection-types (probably limited to integer indices, although a special type for Maps wouldn't be too bad).2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger). These have some potential commutativity concerns, so I wouldn't be too miffed if this aspect were left out (although limited operator overloading without touching basic mathematical operations is... almost pointless).-- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

Joshua Cranmer wrote:> Daniel Pitts wrote:>> Patricia Shanahan wrote:>>> I often choose arrays in preference to collections because of the better>>> notation for accessing and changing elements. Much more to do with code>>> clarity than with performance.>>>> Alas, if only Java supported proper operator overloading :-/> > The two instances in which I can support operator overloading:> 1. Bracketed access for Collection-types (probably limited to integer > indices, although a special type for Maps wouldn't be too bad).> > 2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger). > These have some potential commutativity concerns, so I wouldn't be too > miffed if this aspect were left out (although limited operator > overloading without touching basic mathematical operations is... almost > pointless).> Knowing that any feature can be abused, the intent of +,-,*,/, (maybe %) overloading would be to allow types that have a natural meaning for those operators.  C++'s use of << for streams and Java's use of + for string concatenation are good examples of "what not to do".  Oops.Specifically, I have a "Distance" type that I would like to support +, -, * for.  Also I have a Duration type, and a (mathematical) Vector type, as well as a DistanceOverDuration type, which would be the return for Distance::operator/(Duration duraction) :-)Distance*Distance would return Area, etc...The expressive power of these operators on these types would be very beneficial.The biggest problem is people doing stupid things like "x*y" doesn't mean multiplication.Even in the case of my Vector type, I wouldn't use * for dot or cross products, although I would probably use it for a scalar multiplication.-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Joshua Cranmer wrote:> Daniel Pitts wrote:>> Patricia Shanahan wrote:>>> I often choose arrays in preference to collections because of the better>>> notation for accessing and changing elements. Much more to do with code>>> clarity than with performance.>>>> Alas, if only Java supported proper operator overloading :-/> > The two instances in which I can support operator overloading:> 1. Bracketed access for Collection-types (probably limited to integer > indices, although a special type for Maps wouldn't be too bad).> > 2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger). > These have some potential commutativity concerns, so I wouldn't be too > miffed if this aspect were left out (although limited operator > overloading without touching basic mathematical operations is... almost > pointless).> How do you define "near-numeric"? All values of BigDecimal are numbers,but double has non-numeric values, so BigDecimal seems nearer to numericthan double to me.Mixed type operations can create a lot of complications, so I wouldrather favor no implicit conversion for the overloaded operators.Why not "%"?Patricia

Daniel Pitts wrote:....> The biggest problem is people doing stupid things like "x*y" doesn't > mean multiplication.....What I don't understand is why the operators seem to bring out the worstin programmers. People who would not dream of naming an append to outputfunction "left_shift" happily use "<<" for append to output.Patricia

"Ouabaine" <ouabaine@orange.fr> wrote in message news:474e67d8$0$646$426a74cc@news.free.fr...> Hello,>> When you create an array of numbers, like int array[]=new int[1000]; what > is the initial value of the array? Are all the members set to zero, or is > it undetermined?Set to 0.  The value of a Java object is never undetermined. 

Patricia Shanahan wrote:> Daniel Pitts wrote:> ....>> The biggest problem is people doing stupid things like "x*y" doesn't >> mean multiplication.> ....> > What I don't understand is why the operators seem to bring out the worst> in programmers. People who would not dream of naming an append to output> function "left_shift" happily use "<<" for append to output."Left" "remaining" Or "left" "sinister"?"Shift" "move", "shift" "garment", or "shift" "artifice"?-- John W. Kennedy"Man is a giddy thing."     -- "Much Ado about Nothing"

John W. Kennedy wrote:> Patricia Shanahan wrote:>> Daniel Pitts wrote:>> ....>>> The biggest problem is people doing stupid things like "x*y" doesn't >>> mean multiplication.>> ....>>>> What I don't understand is why the operators seem to bring out the worst>> in programmers. People who would not dream of naming an append to output>> function "left_shift" happily use "<<" for append to output.> > "Left" "remaining" Or "left" "sinister"?> > "Shift" "move", "shift" "garment", or "shift" "artifice"?"Left" - politically liberal."Shift" - period of time at work.-- Lew

On Thu, 29 Nov 2007 08:16:49 +0100, "Ouabaine" <ouabaine@orange.fr>wrote, quoted or indirectly quoted someone who said :>When you create an array of numbers, like int array[]=new int[1000]; what is >the initial value of the array? Are all the members set to zero, or is it >undetermined?see http://mindprod.com/jgloss/array.html-- Roedy Green Canadian Mind ProductsThe Java Glossaryhttp://mindprod.com

In article <474F421C.50302@virtualinfinity.net>,Daniel Pitts  <newsgroup.spamfilter@virtualinfinity.net> wrote:>Joshua Cranmer wrote:>> Daniel Pitts wrote:>>> Patricia Shanahan wrote:>>>> I often choose arrays in preference to collections because of the better>>>> notation for accessing and changing elements. Much more to do with code>>>> clarity than with performance.>>>>>> Alas, if only Java supported proper operator overloading :-/>> >> The two instances in which I can support operator overloading:>> 1. Bracketed access for Collection-types (probably limited to integer >> indices, although a special type for Maps wouldn't be too bad).>> >> 2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger). >> These have some potential commutativity concerns, so I wouldn't be too >> miffed if this aspect were left out (although limited operator >> overloading without touching basic mathematical operations is... almost >> pointless).>> >Knowing that any feature can be abused, the intent of +,-,*,/, (maybe %) >overloading would be to allow types that have a natural meaning for >those operators.  C++'s use of << for streams and Java's use of + for >string concatenation are good examples of "what not to do".  Oops.Java's + bothers me much more than C++'s <<.  The << operator isn't usedall that often in code (you need it if you are writing low level stuff, butthat's about it) so it's a matter of taking a rarely used operator andgiving it a new meaning that is also visually distinct:  cout << foo << bar << baz;  vs.  a = b << 3;It's very easy (IMHO) to tell these two apart. Java's + OTOH, bugs me.  + is a very common operator and has a veryparticular meaning and given Java's "operator overloading is bad, bad,evil" stance it seems bizarre that they take a well known commutativeoperator and give it a different, very common, usage that isn't commutativeand isn't visually distinct from the main one (plus the "auto convertintegers to strings unless they are the first item, in which case gobatshit" is annoying).Alan-- Defendit numerus

Patricia Shanahan wrote:> Daniel Pitts wrote:> ...>> The biggest problem is people doing stupid things like "x*y" doesn't >> mean multiplication.> ...> > What I don't understand is why the operators seem to bring out the worst> in programmers. People who would not dream of naming an append to output> function "left_shift" happily use "<<" for append to output.> > PatriciaIt's a short, easy way to write code. It may be somewhat obfuscated, but it is a shorthand for (presumably) common operations.I can sort of see how '<<' works for output appending, and '+' for string concatenation makes sense to me, except for the fact that it is already heavily used (but I can't think of any other good operator to use for that...)-- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

Patricia Shanahan wrote:> Joshua Cranmer wrote:>> 2. +,-,*,/ for near-numeric types (i.e., BigDecimal and BigInteger). >> These have some potential commutativity concerns, so I wouldn't be too >> miffed if this aspect were left out (although limited operator >> overloading without touching basic mathematical operations is... >> almost pointless).>>> > How do you define "near-numeric"? All values of BigDecimal are numbers,> but double has non-numeric values, so BigDecimal seems nearer to numeric> than double to me.Near-numeric is a catch-all for anything that could subclass Number and other non-mathematic types (matrices, rings, etc.)> Mixed type operations can create a lot of complications, so I would> rather favor no implicit conversion for the overloaded operators.My personal opinion for how it could be done would be to have something like this:public interface Addable<Addend,Sum> {     public Sum add(Addend o);}This would, however, require reified generics to be able to inherent from the same interface with different generic parameters.> Why not "%"?Um... it slipped my mind.-- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

Joshua Cranmer skrev:> Patricia Shanahan wrote:>> Daniel Pitts wrote:>> ...>>> The biggest problem is people doing stupid things like "x*y" doesn't >>> mean multiplication.>> ...>>>> What I don't understand is why the operators seem to bring out the worst>> in programmers. People who would not dream of naming an append to output>> function "left_shift" happily use "<<" for append to output.>>>> Patricia> > It's a short, easy way to write code. It may be somewhat obfuscated, but > it is a shorthand for (presumably) common operations.> > I can sort of see how '<<' works for output appending, and '+' for > string concatenation makes sense to me, except for the fact that it is > already heavily used (but I can't think of any other good operator to > use for that...)> That's why we decided to skip the operator when concatenating TEXT expressions in Simula. We used juxtaposition, likefilepath := directory "/" file "." ext;Simula, based on Algol 60, with classes and references, is one of the first OO languages. It inspired Bjarne Stroustrup when he designed C++.

Alan Morgan wrote:> Java's + OTOH, bugs me.  + is a very common operator and has a very> particular meaning and given Java's "operator overloading is bad, bad,> evil" stance it seems bizarre that they take a well known commutative> operator and give it a different, very common, usage that isn't commutative> and isn't visually distinct from the main one (plus the "auto convert> integers to strings unless they are the first item, in which case go> batshit" is annoying).I suppose I get your objection to the overload of '+' for string catenation, but it's so common and so well-established that I myself am not bothered by it.  What I do not understand is the "unless they are the first item, in which case go batshit" reference.  To what are you referring?-- Lew

Lew wrote:> Alan Morgan wrote:>> Java's + OTOH, bugs me.  + is a very common operator and has a very>> particular meaning and given Java's "operator overloading is bad, bad,>> evil" stance it seems bizarre that they take a well known commutative>> operator and give it a different, very common, usage that isn't >> commutative>> and isn't visually distinct from the main one (plus the "auto convert>> integers to strings unless they are the first item, in which case go>> batshit" is annoying).> > I suppose I get your objection to the overload of '+' for string > catenation, but it's so common and so well-established that I myself am > not bothered by it.  What I do not understand is the "unless they are > the first item, in which case go batshit" reference.  To what are you > referring?> I think its "okay", but it would have been a better choice to introduce a new operator. # comes to mind for some reason:int fun = 3;int guilt = 0;String myString = fun # " times the fun. " # guilt # " times the guilt";Now that I think about it, why hasn't # been used for any operator?-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:> Lew wrote:>> Alan Morgan wrote:>>> Java's + OTOH, bugs me.  + is a very common operator and has a very>>> particular meaning and given Java's "operator overloading is bad, bad,>>> evil" stance it seems bizarre that they take a well known commutative>>> operator and give it a different, very common, usage that isn't >>> commutative>>> and isn't visually distinct from the main one (plus the "auto convert>>> integers to strings unless they are the first item, in which case go>>> batshit" is annoying).>>>> I suppose I get your objection to the overload of '+' for string >> catenation, but it's so common and so well-established that I myself >> am not bothered by it.  What I do not understand is the "unless they >> are the first item, in which case go batshit" reference.  To what are >> you referring?>>> I think its "okay", but it would have been a better choice to introduce > a new operator. # comes to mind for some reason:> > int fun = 3;> int guilt = 0;> String myString = fun # " times the fun. " # guilt # " times the guilt";> Now that I think about it, why hasn't # been used for any operator?But what is all this about "unless they are the first item ... batshit"?-- Lew

Lew wrote:> Daniel Pitts wrote:>> Lew wrote:>>> Alan Morgan wrote:>>>> Java's + OTOH, bugs me.  + is a very common operator and has a very>>>> particular meaning and given Java's "operator overloading is bad,>>>> bad, evil" stance it seems bizarre that they take a well known>>>> commutative operator and give it a different, very common, usage>>>> that isn't commutative>>>> and isn't visually distinct from the main one (plus the "auto>>>> convert integers to strings unless they are the first item, in>>>> which case go batshit" is annoying).>>>>>> I suppose I get your objection to the overload of '+' for string>>> catenation, but it's so common and so well-established that I myself>>> am not bothered by it.  What I do not understand is the "unless they>>> are the first item, in which case go batshit" reference.  To what>>> are you referring?>>>>> I think its "okay", but it would have been a better choice to>> introduce a new operator. # comes to mind for some reason:>>>> int fun = 3;>> int guilt = 0;>> String myString = fun # " times the fun. " # guilt # " times the>> guilt"; Now that I think about it, why hasn't # been used for any>> operator?>> But what is all this about "unless they are the first item ...> batshit"?Perhaps that    2 + 4 + " is the answer"works very differently from    "The answer is " + 2 + 4.I like Daniels' suggestion;.  It's very clear that both operands must be converted to a string value (except for the ones that are already declared as strings, of course.). 

Lew wrote:> Daniel Pitts wrote:>> Lew wrote:>>> Alan Morgan wrote:>>>> Java's + OTOH, bugs me.  + is a very common operator and has a very>>>> particular meaning and given Java's "operator overloading is bad, bad,>>>> evil" stance it seems bizarre that they take a well known commutative>>>> operator and give it a different, very common, usage that isn't >>>> commutative>>>> and isn't visually distinct from the main one (plus the "auto convert>>>> integers to strings unless they are the first item, in which case go>>>> batshit" is annoying).>>>>>> I suppose I get your objection to the overload of '+' for string >>> catenation, but it's so common and so well-established that I myself >>> am not bothered by it.  What I do not understand is the "unless they >>> are the first item, in which case go batshit" reference.  To what are >>> you referring?>>>>> I think its "okay", but it would have been a better choice to >> introduce a new operator. # comes to mind for some reason:>>>> int fun = 3;>> int guilt = 0;>> String myString = fun # " times the fun. " # guilt # " times the guilt";>> Now that I think about it, why hasn't # been used for any operator?> > But what is all this about "unless they are the first item ... batshit"?> I don't know, that wasn't me.Although, I suspect the problem is in this case:int foo = 1, bar = 2;String s = foo + bar + "3";The output is 33, where as using a different operator would prevent that ambiguity.String s = foo#bar#"3"; // 123-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Lew wrote:> Daniel Pitts wrote:>> Lew wrote:>>> Alan Morgan wrote:>>>> Java's + OTOH, bugs me.  + is a very common operator and has a very>>>> particular meaning and given Java's "operator overloading is bad, bad,>>>> evil" stance it seems bizarre that they take a well known commutative>>>> operator and give it a different, very common, usage that isn't >>>> commutative>>>> and isn't visually distinct from the main one (plus the "auto convert>>>> integers to strings unless they are the first item, in which case go>>>> batshit" is annoying).>>>>>> I suppose I get your objection to the overload of '+' for string >>> catenation, but it's so common and so well-established that I myself >>> am not bothered by it.  What I do not understand is the "unless they >>> are the first item, in which case go batshit" reference.  To what are >>> you referring?>>>>> I think its "okay", but it would have been a better choice to >> introduce a new operator. # comes to mind for some reason:>>>> int fun = 3;>> int guilt = 0;>> String myString = fun # " times the fun. " # guilt # " times the guilt";>> Now that I think about it, why hasn't # been used for any operator?> > But what is all this about "unless they are the first item ... batshit"?> I don't know, that wasn't me.Although, I suspect the problem is in this case:int foo = 1, bar = 2;String s = foo + bar + "3";The output is 33, where as using a different operator would prevent that ambiguity.String s = foo#bar#"3"; // 123-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

On Fri, 30 Nov 2007 17:24:28 -0800, Daniel Pitts<newsgroup.spamfilter@virtualinfinity.net> wrote:>Lew wrote:>> Alan Morgan wrote:>>> Java's + OTOH, bugs me.  + is a very common operator and has a very>>> particular meaning and given Java's "operator overloading is bad, bad,>>> evil" stance it seems bizarre that they take a well known commutative>>> operator and give it a different, very common, usage that isn't >>> commutative>>> and isn't visually distinct from the main one (plus the "auto convert>>> integers to strings unless they are the first item, in which case go>>> batshit" is annoying).>> >> I suppose I get your objection to the overload of '+' for string >> catenation, but it's so common and so well-established that I myself am >> not bothered by it.  What I do not understand is the "unless they are >> the first item, in which case go batshit" reference.  To what are you >> referring?>> >I think its "okay", but it would have been a better choice to introduce >a new operator. # comes to mind for some reason:>>int fun = 3;>int guilt = 0;>String myString = fun # " times the fun. " # guilt # " times the guilt";>Now that I think about it, why hasn't # been used for any operator?Because traditionally # and $ were used for substitution parameters inscripting languages.George--for email reply remove "/" from address

On Fri, 30 Nov 2007 22:18:22 -0500, George Neuner<gneuner2/@/comcast.net> wrote:>On Fri, 30 Nov 2007 17:24:28 -0800, Daniel Pitts><newsgroup.spamfilter@virtualinfinity.net> wrote:>>>Now that I think about it, why hasn't # been used for any operator?>>Because traditionally # and $ were used for substitution parameters in>scripting languages.Forgot % and @ which are also used by scripting languagesGeorge--for email reply remove "/" from address

Lew wrote:> Alan Morgan wrote:>> Java's + OTOH, bugs me.  + is a very common operator and has a very>> particular meaning and given Java's "operator overloading is bad, bad,>> evil" stance it seems bizarre that they take a well known commutative>> operator and give it a different, very common, usage that isn't >> commutative>> and isn't visually distinct from the main one (plus the "auto convert>> integers to strings unless they are the first item, in which case go>> batshit" is annoying).> > I suppose I get your objection to the overload of '+' for string > catenation, but it's so common and so well-established that I myself am > not bothered by it.  What I do not understand is the "unless they are > the first item, in which case go batshit" reference.  To what are you > referring?The only language I can think of offhand with a completely unique concatenation operator is PL/I, which uses "||" for concatenation and nothing else.-- John W. Kennedy"Though a Rothschild you may beIn your own capacity,     As a Company you've come to utter sorrow--But the Liquidators say,'Never mind--you needn't pay,'     So you start another company to-morrow!"   -- Sir William S. Gilbert.  "Utopia Limited"

John W. Kennedy wrote:> The only language I can think of offhand with a completely unique > concatenation operator is PL/I, which uses "||" for concatenation and > nothing else.There is a language that indicates concatenation by a lack of any operator - simply separating terms by blanks imputes concatenation - SNOBOL.-- Lew

Lew wrote:> John W. Kennedy wrote:>> The only language I can think of offhand with a completely unique>> concatenation operator is PL/I, which uses "||" for concatenation and>> nothing else.> > There is a language that indicates concatenation by a lack of any> operator - simply separating terms by blanks imputes concatenation -> SNOBOL.> *grin*I was going to post that, I even found my old SNOBOL4 programming languagemanual to check it.  But I thought "who beside me has ever heard ofSNOBOL?" and canceled my post.SNOBOL was fun, I miss it.Modern C uses a restricted version of this, for string literals.-Wayne

On 2007-11-30 20:19:22 -0800, "John W. Kennedy" <jwkenne@attglobal.net> said:> Lew wrote:>> Alan Morgan wrote:>>> Java's + OTOH, bugs me.  + is a very common operator and has a very>>> particular meaning and given Java's "operator overloading is bad, bad,>>> evil" stance it seems bizarre that they take a well known commutative>>> operator and give it a different, very common, usage that isn't commutative>>> and isn't visually distinct from the main one (plus the "auto convert>>> integers to strings unless they are the first item, in which case go>>> batshit" is annoying).>> >> I suppose I get your objection to the overload of '+' for string >> catenation, but it's so common and so well-established that I myself am >> not bothered by it.  What I do not understand is the "unless they are >> the first item, in which case go batshit" reference.  To what are you >> referring?> > The only language I can think of offhand with a completely unique > concatenation operator is PL/I, which uses "||" for concatenation and > nothing else.SQL-as-specified has the same property, right down to the operator chosen.  Haskell also has a unique list concatenation operator, which covers strings since they're lists too, but I believe you can provide other meanings for ++ within modules, so it may not count.-o

Wayne wrote:> Lew wrote:>> John W. Kennedy wrote:>>> The only language I can think of offhand with a completely unique>>> concatenation operator is PL/I, which uses "||" for concatenation and>>> nothing else.>> There is a language that indicates concatenation by a lack of any>> operator - simply separating terms by blanks imputes concatenation ->> SNOBOL.>>> > *grin*> > I was going to post that, I even found my old SNOBOL4 programming language> manual to check it.  But I thought "who beside me has ever heard of> SNOBOL?" and canceled my post.> > SNOBOL was fun, I miss it.Same here.Patricia

Lew wrote:> John W. Kennedy wrote:>> The only language I can think of offhand with a completely unique >> concatenation operator is PL/I, which uses "||" for concatenation and >> nothing else.> > There is a language that indicates concatenation by a lack of any > operator - simply separating terms by blanks imputes concatenation - > SNOBOL.> There's a current scripting language that does this: awk-- martin@   | Martin Gregoriegregorie. | Essex, UKorg       |

Wayne <nospam@all4me.invalid> wrote:> Lew wrote:> > John W. Kennedy wrote:> >> The only language I can think of offhand with a completely unique> >> concatenation operator is PL/I, which uses "||" for concatenation and> >> nothing else.> >> > There is a language that indicates concatenation by a lack of any> > operator - simply separating terms by blanks imputes concatenation -> > SNOBOL.> >>> *grin*>> I was going to post that, I even found my old SNOBOL4 programming> language manual to check it.  But I thought "who beside me has ever heard> of SNOBOL?" and canceled my post.There are other old guys here.  I was taught SNOBOL when I got my CS degreeback in the 70's.  It was so long ago however and I remember so little ofit that I didn't even think about it while I was reading this thread.+ for string concatenation is as old as the hills.  I used it in a languageI created back in the late 70's.  I can't remember were I first saw it.  Itdoes create a bit of confusion in Java but it's minor and doesn't botherme.  If you wanted a different operator to overload I'd pick |.  It wouldcreate less confusion because the typical context in which you use OR isdifferent from the context in which you would use string concatenation.Other options would be !, or @, or #.  If you wanted to look at multiplecharacters, .. would be a good one, as well as ,, or // or \\ or ><.There's really no end to the options.-- Curt Welch                                            http://CurtWelch.Com/curt@kcwc.com                                        http://NewsReader.Com/

George Neuner wrote:> On Fri, 30 Nov 2007 17:24:28 -0800, Daniel Pitts> <newsgroup.spamfilter@virtualinfinity.net> wrote:>> I think its "okay", but it would have been a better choice to introduce >> a new operator. # comes to mind for some reason:>>>> int fun = 3;>> int guilt = 0;>> String myString = fun # " times the fun. " # guilt # " times the guilt";>> Now that I think about it, why hasn't # been used for any operator?> > Because traditionally # and $ were used for substitution parameters in> scripting languages.> What's that have to do with anything?  # was used in C/C++ as a preprocessor directive marker, and in BASH script to denote comments. Why should the syntax of a language be restricted by the syntax of a completely unrelated language?-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Lew wrote:> John W. Kennedy wrote:>> The only language I can think of offhand with a completely unique >> concatenation operator is PL/I, which uses "||" for concatenation and >> nothing else.> > There is a language that indicates concatenation by a lack of any > operator - simply separating terms by blanks imputes concatenation - > SNOBOL.> PHP uses . for concatenation.  I think perl does too, doesn't it?-- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Lew wrote:> John W. Kennedy wrote:>> The only language I can think of offhand with a completely unique >> concatenation operator is PL/I, which uses "||" for concatenation and >> nothing else.> > There is a language that indicates concatenation by a lack of any > operator - simply separating terms by blanks imputes concatenation - > SNOBOL.REXX partially allows that.-- John W. Kennedy"But now is a new thing which is very old--that the rich make themselves richer and not poorer,which is the true Gospel, for the poor's sake."   -- Charles Williams.  "Judgement at Chelmsford"