 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2006who can tell me why
class Test{ public static void main(String args[]){ String a = new String( "2" ), b; b = a; a = "3"; System.out.println( b ); String c[]= { "1","2","3" }, d[]; d = c; c[0] = "4"; System.out.println( d[0] ); } } in my opinion ,i thought it will print 3 4 but in fact ,it printed 2 4 who can tell me why? > class Test{ > public static void main(String args[]){ [quoted text clipped - 19 lines] > > who can tell me why? Java is strictly pass by value and assignment by value. You do need to appreciate the difference between passing and assigning a primitive value and passing and assigning a reference value. Reference values are pointers to objects and objects may be mutated. In outcome 1, a is a pointer to (the reference value of) String object "2". b is assigned to the reference value of String object "2". a and b now point to the same object. a is then assigned to/bound to/a pointer to a different object. This in no way affects the reference value b is bound to. So System.out.println(b) prints 2 because it remains bound to the reference value of the String object "2". c and d both point to the _same object_ which you then _mutate_. Regards, Adam By the way, comp.lang.java.programmer is intended for more advanced Java programming. Feel free to follow up here but start new topics in comp.lang.java.help. Alright, if i am not wrong, for each String object there is a underlying StringBuffer. String is immutable while StringBuffer is not, as a result, when you reassign a String to a new value, actually it is assigning itself point to another StringBuffer for its value. Thus in your code b=a actually let B points to a StringBuffer object which A is pointing to. a="3" will make A points to a new StringBuffer that has value "3", while B is still pointing to the StringBuffer that has value of "2". EdwardRF > > class Test{ > > public static void main(String args[]){ [quoted text clipped - 41 lines] > programming. Feel free to follow up here but start new topics in > comp.lang.java.help. > Alright, if i am not wrong, for each String object there is a > underlying StringBuffer. String is immutable while StringBuffer is not, > as a result, when you reassign a String to a new value, actually it is > assigning itself point to another StringBuffer for its value. The source code for String and StringBuffer are in the src.zip in any JDK download. They are distinct classes. A String does not have any fields of type StringBuffer. > Thus in your code > b=a > actually let B points to a StringBuffer object which A is pointing > to. b cannot, ever, point to a StringBuffer. Its declared type is String, so it can only be null, or point to a String object. String is final, so it cannot even point to an object of a subclass of String. However, I do agree with your approach of thinking in terms of what the reference variables point at. The immutability of String does not matter. The following program gets exactly the same results, using StringBuffer instead of String throughout: public class TestStringBuffer { public static void main(String args[]) { StringBuffer a = new StringBuffer("2"), b; b = a; a = new StringBuffer("3"); System.out.println(b); StringBuffer c[] = { new StringBuffer("1"), new StringBuffer("2"), new StringBuffer("3") }, d[]; d = c; c[0] = new StringBuffer("4"); System.out.println(d[0]); } } Patricia >Alright, if i am not wrong, for each String object there is a >underlying StringBuffer. There is no underlying StringBuffer, but there is an underlying char[]. However, mutability has nothing to do with the apparent paradox. In the first case he is modifying a reference to an object. In the second he is modifying the object itself.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > class Test{ > public static void main(String args[]){ > String a = new String( "2" ), b; Declare two variables a and b, both type reference to String, and initialize a with a pointer to a newly created String with content "2". > b = a; Copy the pointer to "2" from a to b. > a = "3"; Change a to point to the String literal "3". > System.out.println( b ); Print the String b points at. > String c[]= { "1","2","3" }, d[]; Declare variables c and d to be references to arrays of String references. Create an array of String references containing pointers to the literals "1", "2", and "3", and initialize c with a pointer to it. > d = c; Copy the pointer to the array from c to d. > c[0] = "4"; Change the first element of the array to point to the literal "4". > System.out.println( d[0] ); Print the String pointed to by the first element of the array pointed to by d. > } > } > > in my opinion ,i thought it will print > 3 Why did you expect this? > 4 > but in fact ,it printed [quoted text clipped - 3 lines] > > who can tell me why? On 25 Mar 2006 23:37:48 -0800, "weironghai@gmail.com" <weironghai@gmail.com> wrote, quoted or indirectly quoted someone who said : > class Test{ > public static void main(String args[]){ [quoted text clipped - 16 lines] > 2 > 4 First rewrite your code in more idiomatic Java. You are using the old C mixed prefix/postfix syntax. I added some comments that might clarify. String a = "2"; // a points to an object "2" String b = a; // b also points to that same object a = "3"; // a points to a new object "3" System.out.println( b ); // print what b points to: "2" String[] c = { "1","2","3" }; // c points to an object 1,2,3 String[] d = c; // d points to that same object 1,2,3 c[0] = "4"; // modify the first slot of the object so it becomes 4,2.3 System.out.println( d[0] ), // display the first slot of the object: 4 SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > First rewrite your code in more idiomatic Java. You are using the old > C mixed prefix/postfix syntax. I added some comments that might > clarify. What do you mean? The only thing you did with the code was to change it to declare one variable on each line. Such things are generally considered to be a personal preference issue. You shouldn't mix idioms into it like its a rule or part of the java spec. /tom >What do you mean? The only thing you did with the code was to change it >to declare one variable on each line. I did that, and changed declarations from int x[] to int[] x style The multi vars per line introduces some nasty gotchas. It usually is not a good idea, especially when declaring arrays. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > The multi vars per line introduces some nasty gotchas. It usually is > not a good idea, especially when declaring arrays. You are talking about this line? String c[]= { "1","2","3" }, d[]; What nasty stuff are you thinking of? /tom >What nasty stuff are you thinking of? What does this mean spelled out in single line form? int[] c, d[], e; SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >> What nasty stuff are you thinking of? > > What does this mean spelled out in single line form? > > int[] c, d[], e; int array C, int array d and int e. Its only the first one that might be misunderstood, but only the first time. As soon as you know this, then its no problem anymore. But as I said in the other post, the first array syntax it is of course less readable than the second and the third. /tom >>> What nasty stuff are you thinking of? >> [quoted text clipped - 8 lines] > said in the other post, the first array syntax it is of course less > readable than the second and the third. Hold on with this one until the other post is examined, either there is a bug in the jvm or there is duplicate meanings. Just see the see my post from 12:38 today. /tom -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message tom fredriksen schreef: >>> What nasty stuff are you thinking of? >> [quoted text clipped - 8 lines] > said in the other post, the first array syntax it is of course less > readable than the second and the third. Well, you more than justified Roedy's point here, in giving the false answer. Thus you are only contradicting yourself. int[] c; int[][] d; int[] e; would have been the single line form. H. SignatureHendrik Maryns ================== www.lieverleven.be http://aouw.org >> The multi vars per line introduces some nasty gotchas. It usually is >> not a good idea, especially when declaring arrays. [quoted text clipped - 4 lines] > > What nasty stuff are you thinking of? Probably something like this: <dangerousCode> String []c = {"1", "2", "3"}, d[]; </dangerousCode> Here it looks like d is array of String, but actually it's an array of array of String. - Oliver >> What nasty stuff are you thinking of? > [quoted text clipped - 6 lines] > Here it looks like d is array of String, but actually it's an array of > array of String. I just realised something, I dont know if its an error in the jvm or not but have a look at this: ( My jvm version is "1.5.0_04" ) String [][]c = new String[3][3], d[] = new String[3]; StringArray.java:9: incompatible types found : java.lang.String[][] required: java.lang.String[][][] String [][]c = new String[3][3], d[] = new String[3][3]; ^ d is compiled as an [][][] array as you say, but if you do this String c[][] = new String[3][3], d[] = new String[3]; then d is compiled as [] only. I am used to writing the array designation after the variable, hence my interpretation. Basically, just because the [][] is next to the type definition int it decides that everything on the line is of at least that type, but if its on the right side of the variable or used on any of the following variables then its just what is stated, that's a weird and confusing rule. Is this the correct function of the jvm or is it a bug? /tom > Basically, just because the [][] is next to the type definition int it > decides that everything on the line is of at least that type, but if its > on the right side of the variable or used on any of the following > variables then its just what is stated, that's a weird and confusing rule. > > Is this the correct function of the jvm or is it a bug? That's the correct way for the compiler to work. If you write String[][] v1, v2; then both v1 and v2 are declared to have the type String[][]. This is just like how if you write: String v1, v2; then both v1 and v2 are declared to have the type String. Now if you decorate the declaration of either variable: String v1[], v2[][]; then v1 has type String[], and v2 has type String[][]. It has nothing to do with what's "next to" what, but a [] following a type name qualifies that type, a [] following a variable name qualifies that variable's type. If you mix the two, and especially if you declare multiple variables with mixed qualification, then it gets confusing (for the reader) pretty quickly. That is a known problem in C; which is why Java has the more sensible syntax where the typename itself is qualified. For some reason the Java designers didn't leave out the old-style C-ish (qualify the variable) approach. I don't know why not, but the universal recommendation (as far as I can see) is that you don't use it. -- chris >> Basically, just because the [][] is next to the type definition int it >> decides that everything on the line is of at least that type, but if its [quoted text clipped - 32 lines] > but the universal recommendation (as far as I can see) is that you don't use > it. Ok, fair enough. I wasn't aware that it was an issue with arrays, but now I know. Thanks. /tom ... > Basically, just because the [][] is next to the type definition int it > decides that everything on the line is of at least that type, but if its [quoted text clipped - 4 lines] > > /tom Another USENET group, to which I used to contribute, had a group virtual soapbox that one could call for when needed. I need the comp.lang.java.programmer soapbox. Here, Soapy! [Patricia climbs on the soapbox] The first part of the rule, that the type of the variables in the declaration is the one specified immediately before the first identifier, is a simple, clean rule and in my opinion should have been the ONLY way of declaring the type of a variable. The second part, the ability to add array dimensions for a single identifier by adding one or more "[]" pairs immediately after it, can destroy that simple, clean picture, but only if you use it. I consider the ability to scatter type information among the list of variable identifiers in a single declaration to be a bug in the JLS, and very unfortunate. If multiple variables are to be declared in a single declaration, shouldn't they all have the same type? It is not a bug in the JVM, because it has follow the JLS. It had some point in C, because of the ability to declare a struct without naming the type: struct{ /* a bunch of field declarations */ } a, b[3], c; In Java, each type has a name modified by at most a few "[]" pairs. As far as I can tell, the ability to add array dimensions for a single identifier is in there for the sake of superficial, but potentially confusing, familiarity for C programmers. It apparently even managed to confuse Tom, by making him think Java declarations are more similar to C declarations than is actually the case. I don't think C declaration syntax should be emulated by other languages as a high point of programming language design. There is even a widely distributed program, cdecl, for encoding and decoding C declarations, the ultimate condemnation of their usability. See http://linuxcommand.org/man_pages/cdecl1.html. [Patricia gets off the soapbox, thanks it, and sends it on its way.] Patricia Patricia Shanahan sez: ... array decl ... > It had some point in C, because of the ability to declare a struct > without naming the type: > > struct{ > /* a bunch of field declarations */ > } a, b[3], c; NitPick: it had a point in C because C doesn't really have arrays, it has contiguous storage for n elements of a given type. What int a, b[3]; says is "allocate space for one int on stack and call it 'a', allocate 3*sizeof(int) space on stack and call it 'b'". Which is obviously not what happens in Java. Dima (and I wish they dropped the "everything is a function" idea too) SignatureI like the US government, makes the Aussie one look less dumb and THAT is a pretty big effort. -- Craig Small >Is this the correct function of the jvm or is it a bug? it is a gotcha, the reason I recommend people stay away from multiple declarations per line. It leads to code that people will misread. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Such things are generally >considered to be a personal preference issue. The old mixed prefix/postfix syntax was a temporary sop to C programmers to make them feel at home. Using it in Java is a bit like using "Thee" and "thou" in English. It marks you as from another era. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >> Such things are generally >> considered to be a personal preference issue. > > The old mixed prefix/postfix syntax was a temporary sop to C > programmers to make them feel at home. Using it in Java is a bit like > using "Thee" and "thou" in English. It marks you as from another era. Sorry, but no. Thats your preference and feelings. Its still legal syntax. Writing the following is a similar issue. int []iArr int[] iArr int iArr[] I agree that there are issues with these different syntaxes for both my, yours and other examples. But, some issues are personal taste and other can be misunderstood. Example: int[] iArr,jArr // readability issue: are both arrays? int i=5, b; // no issue, can not be misunderstood int iArr[] and int []iArr // no issue, both are just personal taste. int iArr[] = {1,2}, jArr[] = {3,4} and int iArr[] = {1,2} int jArr[] = {3,4} The first example is a bit less readable than the last two, but no issue just preference. /tom >Sorry, but no. Thats your preference and feelings. Its still legal >syntax. Writing the following is a similar issue. It is legal, but so are lower case class names, capitalised locals and \u package names. Being legal does not make it accepted practice. Look what Sun does. The only people who use that syntax are C-speaking newbies to Java. If you adopt that anachronism, people will presume you are a C-speaking newbie to Java. If you don't mind that, and you think the old syntax is preferable, go ahead. You will mildly irritate others by refusing to use the more common idiom, the same way you would if you ignored the caps conventions. It just trips people up to have things specified a different way than they expect. You could also use reverse indentation too. That's legal, but will make people do a double take to understand your code. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > The only people who use that syntax are C-speaking newbies to Java. > If you adopt that anachronism, people will presume you are a [quoted text clipped - 3 lines] > you ignored the caps conventions. It just trips people up to have > things specified a different way than they expect. If you're talking about doing something like int b = 5, c = 7, d = 8; ... I do that all the time. And I have way more experience in Java than C. Make of that what you will. When you have class names that are 20, 30, or more characters long, I see no reason to type them more often than necessary ... even with autocomplete, you do have to type a little bit. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html ... > When you have class names that are 20, 30, or more characters > long, I see no reason to type them more often than necessary ... > even with autocomplete, you do have to type a little bit. You either think a lot faster or type a lot slower than I do when programming. Except when using punch cards, with no backspace-erase, I've never been limited by typing speed. I can type at least enough to keep an autocomplete happy in less time than it take me to think up a good variable identifier. Patricia > Monique Y. Mudama wrote: ... >> When you have class names that are 20, 30, or more characters [quoted text clipped - 8 lines] > autocomplete happy in less time than it take me to think up a good > variable identifier. Oh ... I wasn't really talking about typing speed. I type a lot, a whole lot, so anything I don't have to type is great. I use tab complete in irc to complete five letter nicks! Also, wasteful repetition irritates me. You know how it's annoying to see someone repeat the same set of instructions several times, rather than iterating over the data set? I feel that way, only to a lesser degree, about unnecessarily repeating types. If it helps the clarity to split things up with new entries, that's great. I just don't think that int i, j; is any less clear than int i; int j; To me, the second version is actually less clear, because I have to notice the type for both. Granted, both aren't exactly difficult to read. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > int i, j; > [quoted text clipped - 5 lines] > To me, the second version is actually less clear, because I have to > notice the type for both. FWIW, I prefer the first form if the several variables /must/ have the same type, and the second if the two (or more) types are related only by "accident". -- chris >> int i, j; >> [quoted text clipped - 8 lines] > FWIW, I prefer the first form if the several variables /must/ have the same > type, and the second if the two (or more) types are related only by "accident". Actually, yeah, I like to group related variables together. For example, I am using static Strings in a few places to act as entries in a drop-down of some sort ... I would typically declare each drop-down's set of entries on a separate line. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html thanks for your helping .now i know why it is. > You will mildly irritate others by refusing > to use the more common idiom, the same way you would if you ignored [quoted text clipped - 3 lines] > You could also use reverse indentation too. That's legal, but will > make people do a double take to understand your code. You have to differentiate between what make things more readable and what are just preferences. Reverse indentation (don't know what it is though:), I presume would make the code a lot less readable and would make maintenance costs sky rocket. Where you put your array definition and whether you write { on the same line or the next is a preference and is just part of life, you are never going to get every programmer in the world to follow that unless its a rule in the compiler. Its just one of those things. /tom > Where you put your array definition and whether you write { on the same > line or the next is a preference and is just part of life, you are never > going to get every programmer in the world to follow that unless its a > rule in the compiler. Its just one of those things. After realising that there are issues with arrays syntax, I agree. But for other similar issues where there are no semantic difference, I still hold the opinion that its just a preference. /tom >After realising that there are issues with arrays syntax, I agree. But >for other similar issues where there are no semantic difference, I still >hold the opinion that its just a preference. That is illogical. If others disagree with you, then obviously it does matter even if just to reduce friction. You could only justify your stance in a vacuum. As soon as you show your code to others, you have a potential to get their backs up with eccentricities. You then get into a cost benefit situation. Is the benefit of doing things an eccentric way worth the hassles when dealing with others. Usually there are good reasons why the world settles on a consensus, for example the use of int[] x rather than int x[]. If you pick conventions just to be different or arbitrarily, you will usually be missing out on some benefit. It seems odd to aim to write code as hackneyed as possible, full of as many trite idioms as possible, but that is what is easiest to maintain. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Usually there are good reasons why the world settles on a consensus, > for example the use of int[] x rather than int x[]. If you pick > conventions just to be different or arbitrarily, you will usually be > missing out on some benefit. This argument assumes that it's clear to the OP that there is a consensus, and that the OP is willfully choosing to be contrary; perhaps in the OP's experience, both styles of declaration are equally common, thus explaining why the OP came to the conclusion that it was just a matter of preference. - Oliver >Reverse indentation (don't know what it is though:), I presume would >make the code a lot less readable and would make maintenance costs sky >rocket. It is just nutty I idea I made up to poke fun at the idea it is ok to code in any way that is legal.. Instead of writing: void myMethod ( int parm ) { for ( int i=0; i<n; i++) { sum+= a[i]; } } you would code: void myMethod ( int parm ) { for ( int i=0; i<n; i++) { sum+= a[i]; } } SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >Where you put your array definition and whether you write { on the same >line or the next is a preference and is just part of life, you are never >going to get every programmer in the world to follow that unless its a >rule in the compiler. Its just one of those things. I take it, Tom, that you have never worked on a team. In order to avoid false deltas, usually a team will have EXTREMELY tight coding conventions, much stricter than the ones Sun suggests. See http://mindprod.com/jgloss/codingconventions.html If you don't follow them, you will soon find yourself on the street. Programming is as much a human-to-human communication enterprise as a human-to-computer. The conventions also make it easier to see standard idioms at a glance. Have a look at Eclipse or IntelliJ. They goes on for pages and pages defining in minute detail how to format your code. In a team, everyone uses the same template. Even if you work solely on your own, you will find you can comprehend your own code more easily the more consistent you are. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >> After realising that there are issues with arrays syntax, I agree. But >> for other similar issues where there are no semantic difference, I still >> hold the opinion that its just a preference. > [quoted text clipped - 13 lines] > many trite idioms as possible, but that is what is easiest to > maintain. > I take it, Tom, that you have never worked on a team. In order to > avoid false deltas, usually a team will have EXTREMELY tight coding > conventions, much stricter than the ones Sun suggests. See > http://mindprod.com/jgloss/codingconventions.html > > If you don't follow them, you will soon find yourself on the street. Now you are just being silly, is this is how far the discussion has gone, that you have no more constructive arguments and feel you need to resort to the "descrediting game"? I have no problem with your point of view or that you express or discussing the postives and the negatives of it, but please refrain from trying to impress on me or others your view. Thats not really very becoming, of anybody. I recently had a similar discussion with a consultant working with me at my workplace. He was trying to set a rule that import should be written with the class name, not with *. Do you know what his reason was? He claimed it was faster, implying that it was so for the compiler and the runtime. Now we all know that it is not so, and I corrected him on that. Do you know what his motivation was? He had this problem that he is a Sun Java Champion and he is a chief consultant at his company, so in his mind he needs to be right, ALL THE TIME, sounds familiar? What he did not say, which he could have, was that since he uses intellij its automagic and therefore mixing such statements makes the code look ugly or something Instead he chose to try to force his will on the rest of the team. It ended up with with me having to tell him where the line is in the team. If these things are such issues, it would have been included in any langauge spec. Its really a non-issue, which most people dont care about anymore, they want to spend their time where it matters. I am not saying readability and maintainability are not important, I am saying some issues are just to tiny to bother with. You must realise that the world IS a messy place, you can't go around with a belief that people are this or that just because they don't follow your rules. Take any given human language, 99% of all native speakers make grammatical mistakes while speaking or writing. Do you see many people care about that, no. What you see, once in a while, is some language professor going crazy about it in some newspaper under the section readers comments and calling for the entire nation to stop until it's fixed. That's the way it is with anything in the world, some things are minor issue, and people can't be bothered to spend any energy on it. Most projects I have worked on there has been some rules, but they have little to do with pretty syntax, but rather with semantics and avoiding bugs. F.ex at my workplace we are making embedded voip software and one of the rules we have is: instead of writing if(some_var==SOME_MAGIC_NUMBER) do something we write if(SOME_MAGIC_NUMBER==some_var) do something (with SOME_MAGIC_NUMBER being a C define), do you see why one would write it like this? It has to do with reducing the number of bugs in the software, that's the kind of things they care about. The consensus in projects I have worked on is that as long as its readable, semantically the same and reasonably similar you can do what you want. Most people I have met don't care about the old syntax pissing contest any more. So, if you could stop trying to force your will on others that would be nice, if not, it shows lack of basic human respect on your part. I have no problem with your opinion on the matter, its your perogative and you can do what you want. But stop the "I am the senior here, you SHOULD do what I want" game. If you dont have a decent and constructive argument, then you should not particiapte in the discussion. I will do my best as well, I know I have much to learn about java and thats where I want to focus my energy. Agreed? > Have a look at Eclipse or IntelliJ. They goes on for pages and pages > defining in minute detail how to format your code. In a team, > everyone uses the same template. Eclipse and intellij are for beginning programmers, I write all my code in emacs or was it vi? hmm... never mind:) /tom > I recently had a similar discussion with a consultant working with me at > my workplace. He was trying to set a rule that import should be written [quoted text clipped - 8 lines] > Instead he chose to try to force his will on the rest of the team. It > ended up with with me having to tell him where the line is in the team. The consultant gave a "bad reason", but there IS a point to using full class names instead of ".*" in import statements: to avoid name conflicts. - Oliver > but there IS a point to using > full class names instead of ".*" in import statements: to avoid name > conflicts. If you are thinking of the problem of two packages having the different classes with same names, then using the complete package name in the code statement is the only viable solution, for readability and code safety. If you are thinking of two classes with the same name in the same package, is that even legal? > The consultant gave a "bad reason", The main point was that he wanted to have it his way by force if necessary. /tom >> but there IS a point to using full class names instead of ".*" in import >> statements: to avoid name conflicts. [quoted text clipped - 4 lines] > If you are thinking of two classes with the same name in the same package, > is that even legal? I was thinking of the former. Just as an example off the top of my head, maybe you're writing a class which does SQL stuff, and puts things into collections. If you write: import java.sql.*; import java.util.*; You'll get a collision with the classname "Date", because there exists a java.sql.Date and a java.util.Date. If you instead wrote: import java.sql.Connection; import java.sql.Date; import java.sql.ResultSet; import java.sql.Statement; import java.util.ArrayList; import java.util.List; you avoid the name collision. - Oliver > I was thinking of the former. Just as an example off the top of my > head, maybe you're writing a class which does SQL stuff, and puts things [quoted text clipped - 12 lines] > import java.util.ArrayList; > import java.util.List; Only if you do not specify the package name in front of the class name when declaring the variable, would there be a problem. But I see your point though, basically there is pro and cons to the issue. /tom >> I was thinking of the former. Just as an example off the top of my >> head, maybe you're writing a class which does SQL stuff, and puts things [quoted text clipped - 16 lines] > when declaring the variable, would there be a problem. But I see your > point though, basically there is pro and cons to the issue. Why would you routinely specify the package name in a declaration, rather than just importing it? The only reason I can think of for doing so is when you actually do use both Dates (or whatever other class has a name conflict) in a file. Signaturemonique Ask smart questions, get good answers: http://www.catb.org/~esr/faqs/smart-questions.html > Why would you routinely specify the package name in a declaration, > rather than just importing it? Not routinely, just when its an issue. In any case, I am not saying one way or the other, I am just making a remark. /tom >> but there IS a point to using full class names instead of ".*" in >> import statements: to avoid name conflicts. [quoted text clipped - 3 lines] > code statement is the only viable solution, for readability and code > safety. The potential problem with wildcard import is the risk that the program will stop compiling without any source code change. Addition of a class name to a package you are importing can make an existing identifier ambiguous. If you use only class imports, that will never happen, because the new identifier is not imported. Patricia >The potential problem with wildcard import is the risk that the program >will stop compiling without any source code change. Addition of a class [quoted text clipped - 3 lines] >If you use only class imports, that will never happen, because the new >identifier is not imported. The other advantage of the explicit list is it gives you a very quick overview of what the class is up to, and what it CAN'T be doing. The tools in Eclipse and IntelliJ to flip back and forth between * and explicit notation, pruning excess and also adding needed imports make maintaining such an explicit list painless. Without such a tool, maintaining the list is a pain. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >I have no problem with your point of view or that you express or >discussing the postives and the negatives of it, but please refrain from >trying to impress on me or others your view. Thats not really very >becoming, of anybody. Your attitudes are typical of the young and self taught. The real world is much bigger. You are already running into the friction here is only a tiny foretaste of the volcanic fury you will generate if you keep those attitudes on team project. I am not some sort of Nazi who want's uniformity in order to control others. I have been pushing for the SCID to allow maximum individual flexibility without infringing on the rights of others to read the code the way THEY like. See http://mindprod.com/jgloss/scid.html If you want to rebel, do it with something that matters, not with a nose ring or archaic Java syntax. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >> I have no problem with your point of view or that you express or >> discussing the postives and the negatives of it, but please refrain from [quoted text clipped - 13 lines] > If you want to rebel, do it with something that matters, not with a > nose ring or archaic Java syntax. You are calling me a rebel because I have a legitimate preference for some things? Come on, you are loosing the discussion, and you dont want to admit it. /tom >You are calling me a rebel because I have a legitimate preference for >some things? Come on, you are loosing the discussion, and you dont want >to admit it. If you insist on top posting you will drive some people in this forum apoplectic. I would not mind in the least personally, but I would not want you doing it, to preserve the peace. Every group has its conventions. You are new and inexperienced. You are stomping over established conventions, including ones you don't even understand. It is as if you were thumbing your nose at everyone. I am going to plonk you. I am already overstating my case. I have not the energy to deal with you. I don't want to explode in the nasty ad hominem that I can feel brewing. The humour is I can see how my own behaviour, similar to yours, especially in my early career, was so grating on others. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Every group has its conventions. You are new and inexperienced. You > are stomping over established conventions, including ones you don't > even understand. It is as if you were thumbing your nose at everyone. :) you need to explain to me what conventions I am breaking and how you think I am inexperienced. Guide me, please. > I am going to plonk you. For disagreeing with you? on this topic? Come on, its a discussion group, if you don't want to discuss a particular topic with me then you don't have to. but plonking is for when the person never contributes to any discussions. Have been a troll all the time and not contributed even a little bit with my postings the last couple of months? Well, its your prerogative, you do what you feel like. /tom >> I have no problem with your point of view or that you express or >> discussing the postives and the negatives of it, but please refrain from [quoted text clipped - 13 lines] > If you want to rebel, do it with something that matters, not with a > nose ring or archaic Java syntax. I forgot to say, there is only a couple of people I have met (of about 150 programmers I have worked with over the last 12 years both at work and while at university), that have really been annoyed with such minor issues. You and the consultant are the prime candidates though. /tom > instead of writing > [quoted text clipped - 8 lines] > (with SOME_MAGIC_NUMBER being a C define), do you see why one would > write it like this? No I don't actually. This is an obsolete practice from C whose purpose is to avoid the subtle bug that arises if you type '=' instead of '=='. In Java the problem cannot arise, because it is a compile error: assignment doesn't have a boolean value in Java. >> instead of writing >> [quoted text clipped - 13 lines] > In Java the problem cannot arise, because it is a compile error: > assignment doesn't have a boolean value in Java. Assignments of boolean expressions do have type boolean: if(someBooleanVar = (x>3)) compiles and can change the value of someBooleanVar. I am not at all sure that making assignments expressions, rather than statements, was a good thing in Java. It was more useful in C, because of the extensive use of macros that had to be expressions. Patricia >> instead of writing >> [quoted text clipped - 13 lines] > In Java the problem cannot arise, because it is a compile error: > assignment doesn't have a boolean value in Java. I was thinking about C, not java. So in C its valid way of doing it. /tom >>> instead of writing >>> [quoted text clipped - 15 lines] > > I was thinking about C, not java. So in C its valid way of doing it. Either was is valid in C -- LTP :) >>>> instead of writing >>>> [quoted text clipped - 15 lines] > > Either was is valid in C Yes, that was my point. /tom > I take it, Tom, that you have never worked on a team. In order to > avoid false deltas, usually a team will have EXTREMELY tight coding > conventions, much stricter than the ones Sun suggests. Although I have worked on several teams, I have never encountered these "EXTREMELY tight coding conventions" of which you speak, just local recommendations that may or may not vary among code shops. The programmers I've worked with have sufficient sense to refrain from reformatting every piece of code they touch, so the idea that lack of strict rules must necessarily result in a chaos of false diffs is ridiculous. /gordon Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e >Although I have worked on several teams, I have never encountered >these "EXTREMELY tight coding conventions" of which you speak, just >local recommendations that may or may not vary among code shops. Either you ban beautifiers, which I see as like asking people to code with one arm, or you insist than the beautifiers be synchronised with the same rules. I have worked in both kinds of shop. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Either you ban beautifiers, which I see as like asking people to code > with one arm, or you insist than the beautifiers be synchronised with > the same rules. > > I have worked in both kinds of shop. You certainly presume to know a lot about places you *haven't* worked. /gordon Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e weironghai@gmail.com sez: > class Test{ > public static void main(String args[]){ > String a = new String( "2" ), b; > b = a; > a = "3"; > System.out.println( b ); ... prints "2" char *two = "2"; char *three = "3"; char *a = two; char *b = a; a = three; printf( "%s\n", b ); Dima SignatureQ276304 - Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords -- RISKS 21.37 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.