Arrays in java

Discussion in 'Java' started by mmc.java, Jul 9, 2012.

  1. mmc.java

    mmc.java Guest

    I am just starting to learn java and wanted to know when creating an array if there is any reason why you choose one of the following over the others or if it is just a styling choice by the developer

    int productIDs[] = {10,20,30};
    int []productIDs = {10,20,30};
    int[] productIDs = {10,20,30};

    I did notice the the following will cause a compilation error
    []int productIDs = {10,20,30}; //causes an error
     
    mmc.java, Jul 9, 2012
    #1
    1. Advertising

  2. mmc.java

    Eric Sosman Guest

    On 7/9/2012 10:54 AM, mmc.java wrote:
    > I am just starting to learn java and wanted to know when creating an array if there is any reason why you choose one of the following over the others or if it is just a styling choice by the developer
    >
    > int productIDs[] = {10,20,30};
    > int []productIDs = {10,20,30};
    > int[] productIDs = {10,20,30};


    All are equivalent. The first suggests the code was written by
    an immigrant from C or C++, the last is the style usually seen in
    Java, and the middle is just plain ugly.

    > I did notice the the following will cause a compilation error
    > []int productIDs = {10,20,30}; //causes an error


    So will

    int productIDs = []{10,20,30};
    int productIDs = {10,20,30}[];
    int productIDs = {[10,20,30]};
    productIDs int[] = {10,20,30};

    .... and a lot of other random stuff, too.

    --
    Eric Sosman
    d
     
    Eric Sosman, Jul 9, 2012
    #2
    1. Advertising

  3. mmc.java

    markspace Guest

    On 7/9/2012 7:54 AM, mmc.java wrote:
    > I am just starting to learn java and wanted to know when creating an
    > array if there is any reason why you choose one of the following over
    > the others or if it is just a styling choice by the developer



    It's "style choice" but there a convention too, most of the code I've
    seen uses the style below. For readability, I'd recommend it.
    (Readability = it's what everyone is used to seeing.)

    > int[] productIDs = {10,20,30};
     
    markspace, Jul 9, 2012
    #3
  4. On 7/9/2012 10:54 AM, mmc.java wrote:
    > I am just starting to learn java and wanted to know when creating an
    > array if there is any reason why you choose one of the following over
    > the others or if it is just a styling choice by the developer
    >
    > int productIDs[] = {10,20,30};


    This one, I suspect, is a holdover from C/C++, where the array specifier
    has to come after the variable name. I'd recommend not using it, since
    it makes it less clear that 'int[]' is the type.

    > int []productIDs = {10,20,30};
    > int[] productIDs = {10,20,30};


    These two are effectively equivalent, differing only in whether you
    think "int []" or "int[]" is a more natural way to specify the type. I
    tend towards the latter, since "[]" is bound to the int type and not to
    the name of productIDs.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jul 9, 2012
    #4
  5. mmc.java

    Roedy Green Guest

    On Mon, 9 Jul 2012 07:54:39 -0700 (PDT), "mmc.java"
    <> wrote, quoted or indirectly quoted
    someone who said :

    >int[] productIDs = {10,20,30};


    the [] are part of the type so I like to keep them together. The
    other style was to make Java look more like C.

    see http://mindprod.com/jgloss/array.html
    for things a newbie needs to know about arrays.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    Why do so many operating systems refuse to define a standard
    temporary file marking mechanism? It could be a reserved lead character
    such as the ~ or a reserved extension such as .tmp.
    It could be a file attribute bit. Because they refuse, there is no
    fool-proof way to scan a disk for orphaned temporary files and delete them.
    Further, you can't tell where the orhaned files ame from.
    This means the hard disks gradually fill up with garbage.
     
    Roedy Green, Jul 9, 2012
    #5
  6. mmc.java

    Lew Guest

    markspace wrote:
    > mmc.java wrote:
    >> I am just starting to learn java [sic] and wanted to know when creating an
    >> array if there is any reason why you choose one of the following over
    >> the others or if it is just a styling choice by the developer


    The brackets with the type is the more sensible style.

    Putting brackets on the variable splits the type information between the
    beginning and the end of the declaration. It's more sensible to keep
    all the type part of the declaration together.

    > It's "style choice" but there a convention too, most of the code I've
    > seen uses the style below. For readability, I'd recommend it.
    > (Readability = it's what everyone is used to seeing.)
    >
    > > int[] productIDs = {10,20,30};


    It's also logic.

    The array dimensions are part of the type. So the type of 'productIDs'
    in your example is 'int[]'. Splitting that into 'int productIDs[]' is both
    less logical and less readable.

    Regardless of your style choice (i.e., the right style or the wrong one)
    the code conventions require that you not mix types on one line of
    declaration. This is moot of you follow the other convention to
    declare only one variable per line.

    <http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-141270.html#2992>

    Note also that the return type of a method must use the 'int[]' form,
    so varying that for variables makes even less sense.

    --
    Lew
     
    Lew, Jul 9, 2012
    #6
  7. mmc.java

    Daniel Pitts Guest

    On 7/9/12 3:03 PM, Patricia Shanahan wrote:
    > Eric Sosman wrote:
    >> On 7/9/2012 10:54 AM, mmc.java wrote:

    > ...
    >>> I did notice the the following will cause a compilation error
    >>> []int productIDs = {10,20,30}; //causes an error

    >>
    >> So will
    >>
    >> int productIDs = []{10,20,30};
    >> int productIDs = {10,20,30}[];
    >> int productIDs = {[10,20,30]};
    >> productIDs int[] = {10,20,30};
    >>
    >> ... and a lot of other random stuff, too.
    >>

    >
    > I think the OP may be trying to find out why one totally illogical
    > placement of the "[]" works, although another, slightly less illogical,
    > placement does not. At least "[]int" keeps all the type information
    > together.
    >
    > The answer, already given, is to allow C and C++ programmers to use a
    > familiar order.
    >
    > Patricia

    Here is one that'll blow your mind:

    int[] arr[] = {{},{1},{2,3},{4,5,6}};

    I'm guessing you could even do "int[] []arr[]"
     
    Daniel Pitts, Jul 9, 2012
    #7
  8. mmc.java

    Lew Guest

    Daniel Pitts wrote:
    > Here is one that'll blow your mind:
    >
    > int[] arr[] = {{},{1},{2,3},{4,5,6}};
    >
    > I'm guessing you could even do 'int[] []arr[]';


    Yes, but the JLS strongly discourages that.

    “Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets toappear on both the type and in declarators, so that the local variable declaration:

    “ float[][] f[][], g[][][], h[]; // Yechh!

    “We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”

    <http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>

    Know. Don't guess. Read the JLS.

    Chant 12 times until it's ingrained in your subconscious.

    --
    Lew
     
    Lew, Jul 10, 2012
    #8
  9. mmc.java

    Daniel Pitts Guest

    On 7/9/12 4:14 PM, Lew wrote:
    > Daniel Pitts wrote:
    >> Here is one that'll blow your mind:
    >>
    >> int[] arr[] = {{},{1},{2,3},{4,5,6}};
    >>
    >> I'm guessing you could even do 'int[] []arr[]';

    >
    > Yes, but the JLS strongly discourages that.
    >
    > “Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:
    >
    > “ float[][] f[][], g[][][], h[]; // Yechh!
    >
    > “We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”
    >
    > <http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>
    >
    > Know. Don't guess. Read the JLS.

    If it was something I cared to know, I would have. I know that even if
    it was valid, I would never use it. If I ever encountered it, I would
    look up the rules on how exactly it works.

    I was mostly just being goofy with examples of what can be done, even if
    it should be avoided.
     
    Daniel Pitts, Jul 10, 2012
    #9
  10. mmc.java

    Lew Guest

    On 07/09/2012 09:43 PM, Daniel Pitts wrote:
    > On 7/9/12 4:14 PM, Lew wrote:
    >> Daniel Pitts wrote:
    >>> Here is one that'll blow your mind:
    >>>
    >>> int[] arr[] = {{},{1},{2,3},{4,5,6}};
    >>>
    >>> I'm guessing you could even do 'int[] []arr[]';

    >>
    >> Yes, but the JLS strongly discourages that.
    >>
    >> “Brackets are allowed in declarators as a nod to the tradition of C and C++.
    >> The general rules for variable declaration, however, permit brackets to
    >> appear on both the type and in declarators, so that the local variable
    >> declaration:
    >>
    >> “ float[][] f[][], g[][][], h[]; // Yechh!
    >>
    >> “We do not recommend "mixed notation" in an array variable declaration,
    >> where brackets appear on both the type and in declarators.â€
    >>
    >> <http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>
    >>
    >> Know. Don't guess. Read the JLS.

    > If it was something I cared to know, I would have. I know that even if it was
    > valid, I would never use it. If I ever encountered it, I would look up the
    > rules on how exactly it works.
    >
    > I was mostly just being goofy with examples of what can be done, even if it
    > should be avoided.


    Sorry, I should have made it clear that I was speaking of general principle
    for the wider audience. If anything I should have emphasized the validity of
    your observation.

    But lately in particular, and for a long time in general, I have seen a
    tendency for programmers to assume or guess or infer or imagine technical
    information that is readily and authoritatively available. The Internet
    removes much of the excuse for uncertainty, pretty much all of it when it
    comes to Java. Especially things that are baldly and rather aggressively
    stated in the single most seminal and normative Java specification there is,
    the Java specification itself.

    I found the under-five minutes to confirm this particular nugget, via a link
    that had been posted in this very thread multiple times already by Roedy and
    others, to be a negligible burden to incur prior to averring the validity of
    your observation.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, Jul 10, 2012
    #10
  11. mmc.java

    Roedy Green Guest

    On Mon, 9 Jul 2012 16:14:36 -0700 (PDT), Lew <>
    wrote, quoted or indirectly quoted someone who said :

    >Know. Don't guess. Read the JLS.


    And I have explained to you many times that not everyone can make hide
    nor tail of that lawyerly document. YOU can, but perhaps only one in
    100 programmers can accurately decode it. It is plain rude to demand
    newbies use it. Encourage them yes, but don't pretend it as a skill
    everyone is suppose to master to justify their existence. You are
    using it like some frat hazing.

    I further hazard a guess your own ability to decode is somewhat higher
    than it is in reality. You just assert your interpretation is the
    correct one. Any time I read that fool think I can come up with 4
    possible interpretations. . The fault it is the document. It was not
    written for average programmers but to settle lawyerly disputes over
    compiler compliance. That is why they are so many text books to
    explain these things in English to programmers.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    Mathematicians and computer scientists are far more interested
    in impressing you than informing you. If this were not
    so, the tutorials on building a robots.txt file, for example,
    would consist primarily of an annotated example. What you get
    instead are nothing but inscrutable adstract fragments in some
    obscure dialect of BNF.
     
    Roedy Green, Jul 11, 2012
    #11
  12. mmc.java

    Lew Guest

    Roedy Green wrote:
    > Lew wrote, quoted or indirectly quoted someone who said :
    > &gt;Know. Don't guess. Read the JLS.
    >
    > And I have explained to you many times that not everyone can make hide
    > nor tail of that lawyerly document. YOU can, but perhaps only one in
    > 100 programmers can accurately decode it. It is plain rude to demand
    > newbies use it. Encourage them yes, but don't pretend it as a skill


    It is plain stupid and evil of you to recommend that newbies not use it.

    It is the seminal authoritative document that defines Java.

    Your rabid insistence that people ignore it is a huge disservice to those
    learning the language.

    > everyone is suppose to master to justify their existence. You are
    > using it like some frat hazing.


    Which is the better advice in computer programming, to study toward
    an understanding in depth the core definition of the language, or
    to avoid studying the definition of the language?

    What is your problem that gets you foaming at the mouth for the
    mere suggestion that the JLS is the core and pinnacle of knowledge
    about the definition of the language? Your attitude is as inexplicable
    as it is hostile and damaging to those seeking better knowledge.

    > I further hazard a guess your own ability to decode is somewhat higher
    > than it is in reality. You just assert your interpretation is the
    > correct one. Any time I read that fool think I can come up with 4


    Show me where I'm wrong. I'm open to learning new things.

    Are you?

    Why are you so adamant that others recapitulate your shortcomings?

    > possible interpretations. . The fault it is the document. It was not
    > written for average programmers but to settle lawyerly disputes over
    > compiler compliance. That is why they are so many text books to
    > explain these things in English to programmers.


    What exactly do you find unclear about

    “Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets toappear on both the type and in declarators, so that the local variable declaration:

    “ float[][] f[][], g[][][], h[]; // Yechh!

    “We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”

    <http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>

    I would be glad to help you with it.

    --
    Lew
     
    Lew, Jul 12, 2012
    #12
  13. On Wed, 11 Jul 2012 16:21:48 -0700 (PDT), Lew <>
    wrote:

    >Roedy Green wrote:
    >> Lew wrote, quoted or indirectly quoted someone who said :
    >> &gt;Know. Don't guess. Read the JLS.
    >>
    >> And I have explained to you many times that not everyone can make hide
    >> nor tail of that lawyerly document. YOU can, but perhaps only one in
    >> 100 programmers can accurately decode it. It is plain rude to demand
    >> newbies use it. Encourage them yes, but don't pretend it as a skill

    >
    >It is plain stupid and evil of you to recommend that newbies not use it.


    Why? It probably is not intelligible by them.

    >It is the seminal authoritative document that defines Java.


    Sure.

    >Your rabid insistence that people ignore it is a huge disservice to those
    >learning the language.


    He is not doing that.

    >> everyone is suppose to master to justify their existence. You are
    >> using it like some frat hazing.

    >
    >Which is the better advice in computer programming, to study toward
    >an understanding in depth the core definition of the language, or
    >to avoid studying the definition of the language?


    How about not excluding the middle? I read the spec for
    JavaScript and had to give it up partway because so much of it was
    just not worth the trouble. Some of it, yes, but other parts were not
    very clear for someone studying for use. I expect the JLS has the
    same trouble. Most language specs are not written for app programmers
    but rather language implementers.

    >What is your problem that gets you foaming at the mouth for the
    >mere suggestion that the JLS is the core and pinnacle of knowledge
    >about the definition of the language? Your attitude is as inexplicable
    >as it is hostile and damaging to those seeking better knowledge.


    If you are looking for hostility, consider your own.

    >> I further hazard a guess your own ability to decode is somewhat higher
    >> than it is in reality. You just assert your interpretation is the
    >> correct one. Any time I read that fool think I can come up with 4

    >
    >Show me where I'm wrong. I'm open to learning new things.
    >
    >Are you?
    >
    >Why are you so adamant that others recapitulate your shortcomings?


    I think he is trying to avoid them hitting a wall.

    >> possible interpretations. . The fault it is the document. It was not
    >> written for average programmers but to settle lawyerly disputes over
    >> compiler compliance. That is why they are so many text books to
    >> explain these things in English to programmers.

    >
    >What exactly do you find unclear about
    >
    >“Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:
    >
    >“ float[][] f[][], g[][][], h[]; // Yechh!
    >
    >“We do not recommend "mixed notation" in an array variable declaration, where brackets appear on both the type and in declarators.”
    >
    ><http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2>
    >
    >I would be glad to help you with it.


    That an individual example is clear does not prove that the whole
    is clear. Even if all examples are clear, it does not mean that the
    whole coheres.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jul 12, 2012
    #13
  14. mmc.java

    Lew Guest

    Gene Wirchenko wrote:
    > Lew wrote:
    > &gt;What exactly do you find unclear about
    > &gt;
    > &gt;“Brackets are allowed in declarators as a nod to the tradition of Cand C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:
    > &gt;
    > &gt;“ float[][] f[][], g[][][], h[]; // Yechh!
    > &gt;
    > &gt;“We do not recommend &quot;mixed notation&quot; in an array variable declaration, where brackets appear on both the type and in declarators.”
    > &gt;
    > &gt;&lt;http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2&gt;
    > &gt;
    > &gt;I would be glad to help you with it.
    >
    > That an individual example is clear does not prove that the whole
    > is clear. Even if all examples are clear, it does not mean that the
    > whole coheres.


    It is the individual example that sparked Roedy's diatribe. Ergo
    I concluded it must have posed him some difficulties for him to
    gripe about it.

    Regardless, Roedy has expressed difficulty with the JLS and I am
    happy to help him wherever that difficulty lies.

    I am astounded that you join him in apologetics for ignorance.

    Programming is a game of knowledge and mastery. If you deliberately
    exclude the normative documentation for the platform you use,
    you are hurting yourself. If you recommend that others do so as well,
    you are hurting them.

    I extend you the same offer I did to Roedy, Gene. I'd be glad to help
    you with anything in the JLS you find obscure.

    What really puzzles me is Roedy's apparent anger at me for recommending
    the JLS. What the F? Spend the freaking time reading and understanding it,
    reaching for auxiliary sources (such as those by the JLS's own authors) for
    the parts that puzzle you. Study it. I've been studying the various
    incarnations for over a decade. There's no magic, despite how hard Roedy
    tries to enmystify the process. It's just determination and diligence, and
    I dare say a modicum of raw talent for programming that many who
    frequent this forum can lay claim to.

    Don't be an advocate for laziness and ignorance.

    Know. Don't guess. Read the JLS.

    Excoriate anyone who tries to discourage you from doing so.

    --
    Lew
     
    Lew, Jul 12, 2012
    #14
  15. mmc.java

    Daniel Pitts Guest

    On 7/11/12 3:32 PM, Roedy Green wrote:
    > On Mon, 9 Jul 2012 16:14:36 -0700 (PDT), Lew <>
    > wrote, quoted or indirectly quoted someone who said :
    >
    >> Know. Don't guess. Read the JLS.

    >
    > And I have explained to you many times that not everyone can make hide
    > nor tail of that lawyerly document. YOU can, but perhaps only one in
    > 100 programmers can accurately decode it. It is plain rude to demand
    > newbies use it. Encourage them yes, but don't pretend it as a skill
    > everyone is suppose to master to justify their existence. You are
    > using it like some frat hazing.

    I resent being called a newbie :) I'll admit that I was being lazy (due
    to pain, low blood sugar, and sleep deprivation), and should have looked
    up, or at least tested, the assertion that I wrote "I guess" to instead.
     
    Daniel Pitts, Jul 12, 2012
    #15
  16. On Wed, 11 Jul 2012 17:20:37 -0700 (PDT), Lew <>
    wrote:

    >Gene Wirchenko wrote:
    >> Lew wrote:
    >> &gt;What exactly do you find unclear about
    >> &gt;
    >> &gt;“Brackets are allowed in declarators as a nod to the tradition of C and C++. The general rules for variable declaration, however, permit brackets to appear on both the type and in declarators, so that the local variable declaration:
    >> &gt;
    >> &gt;“ float[][] f[][], g[][][], h[]; // Yechh!
    >> &gt;
    >> &gt;“We do not recommend &quot;mixed notation&quot; in an array variable declaration, where brackets appear on both the type and in declarators.”
    >> &gt;
    >> &gt;&lt;http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.2&gt;
    >> &gt;
    >> &gt;I would be glad to help you with it.
    >>
    >> That an individual example is clear does not prove that the whole
    >> is clear. Even if all examples are clear, it does not mean that the
    >> whole coheres.

    >
    >It is the individual example that sparked Roedy's diatribe. Ergo
    >I concluded it must have posed him some difficulties for him to
    >gripe about it.
    >
    >Regardless, Roedy has expressed difficulty with the JLS and I am
    >happy to help him wherever that difficulty lies.
    >
    >I am astounded that you join him in apologetics for ignorance.


    I do no such thing.

    >Programming is a game of knowledge and mastery. If you deliberately
    >exclude the normative documentation for the platform you use,
    >you are hurting yourself. If you recommend that others do so as well,
    >you are hurting them.


    I do not. I do suggest that it is not an appropriate document
    for a newbie.

    >I extend you the same offer I did to Roedy, Gene. I'd be glad to help
    >you with anything in the JLS you find obscure.
    >
    >What really puzzles me is Roedy's apparent anger at me for recommending
    >the JLS. What the F? Spend the freaking time reading and understanding it,
    >reaching for auxiliary sources (such as those by the JLS's own authors) for
    >the parts that puzzle you. Study it. I've been studying the various
    >incarnations for over a decade. There's no magic, despite how hard Roedy
    >tries to enmystify the process. It's just determination and diligence, and
    >I dare say a modicum of raw talent for programming that many who
    >frequent this forum can lay claim to.
    >
    >Don't be an advocate for laziness and ignorance.
    >
    >Know. Don't guess. Read the JLS.
    >
    >Excoriate anyone who tries to discourage you from doing so.


    I have not read the JLS, but as I noted in my post, I did read
    much of the JavaScript standard. There were parts of it that were
    very lucid indeed. I expect that the JLS has lucid portions, too.
    However, there were parts of the JavaScript standard that were very
    obtuse. Were I interested in implementing a JavaScript processor,
    they would probably be just about what I needed, but for app
    programmer level, no, very unclear. I expect that the same is true
    for the JLS.

    Langauge standards and language documentation for programmers are
    two different things with some overlap. I would not wish the standard
    for any language on a newbie to the language. After he has the
    basics, yes, it would be appropriate then.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jul 12, 2012
    #16
  17. mmc.java

    Lew Guest

    Gene Wirchenko wrote:
    ....
    > I have not read the JLS, but ...


    --
    Lew
     
    Lew, Jul 12, 2012
    #17
  18. On Thu, 12 Jul 2012 11:31:01 -0700 (PDT), Lew <>
    wrote:

    >Gene Wirchenko wrote:
    >...
    >> I have not read the JLS, but ...


    Ad hommuch?

    Patricia Shanahan states that she has read the JLS several times
    and that she agrees with me. What cheap shot are you going to use
    against her?

    Language standards have uses, but one of them is not learning the
    language from the start.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, Jul 13, 2012
    #18
  19. mmc.java

    Lew Guest

    Gene Wirchenko wrote:
    > Lew wrote:
    > &gt;Gene Wirchenko wrote:
    > &gt;...
    > &gt;&gt; I have not read the JLS, but ...
    >
    > Ad hommuch?
    >
    > Patricia Shanahan states that she has read the JLS several times
    > and that she agrees with me. What cheap shot are you going to use
    > against her?
    >
    > Language standards have uses, but one of them is not learning the
    > language from the start.


    I don't advocate reading the JLS in order to learn the language from the
    start. If you think that's what I'm saying, read it again.

    I am advocating not ignoring the JLS, and using it as a reference and an
    adjunct to learning the language, so that by the time you consider
    yourself competent in Java there is a reality to that assessment.

    Let me repeat this to avoid misunderstanding:

    I do not advocate using the JLS (by itself) to learn Java.

    I advocate using the JLS to know what is really real about Java

    I excoriate the advice to avoid the JLS. I didn't hear Patricia say
    not to study the JLS. I did hear others say that.

    It is not an ad hominem attack to point out that you are judging
    the JLS without having even made the attempt to read it. That is
    a legitimate consideration when considering whether your opinion
    about the JLS should carry weight. It is nice that you know the
    term ad hominem; now you need to apply it correctly.

    Patricia actually has read the JLS, so of course that criticism
    cannot apply as it does to you, Gene.

    I also never said that reading the JLS is easy. I am saying that
    it is necessary.

    I also claim that actively discouraging people from reading the
    JLS, most particularly if you yourself have never made the effort,
    is advocacy for laziness and incompetence.

    Secondary materials can tell you what they think the JLS means,
    but you have to watch your sources. I now know, for example, that
    any opinion Gene has about what is or is not so about Java is
    suspect, because he has not read it. He depends entirely on
    indirect sources. If his sources are the likes of Gilead Bracha,
    James Gosling, Brian Goetz and Josh Bloch then he might have
    very good knowledge, but I cannot be sure of that. His resistance
    to the JLS is a telling point against trusting his advice.

    Patricia has demonstrated again and again that she knows
    Java better than most people, and that she bases that knowledge
    in part on studying the JLS.

    So, Gene, here's to your straw-man arguments:

    - You refuted the proposition that one should use the JLS to
    learn Java. Congratulations. No one said you should.

    - You refuted the proposition that the JLS is an easy read.
    Congratulations. No one said that it is.

    Here are the points not refuted and still standing:

    - I claimed that the JLS is an essential tool to learning Java,
    along with recommending other useful sources. No one
    has even said that it isn't, much less established that it isn't.

    - I claimed that it doesn't take special intelligence to
    study the JLS, only diligence and continued study. No one
    has tested that proposition either.

    - I claimed that actively discouraging newbies (or anyone
    else) from studying the JLS is a disservice to their learning
    and professional progress. No one has addressed this point.

    I don't understand why anyone sane or helpful would attempt
    to dissuade Java programmers from studying the JLS, or worse
    yet, be proud that they themselves have not.

    No wonder there are so many poor programmers in the business.

    --
    Lew
     
    Lew, Jul 13, 2012
    #19
  20. mmc.java

    Arun GOPI Guest

    On Monday, 9 July 2012 20:24:39 UTC+5:30, mmc.java wrote:
    > I am just starting to learn java and wanted to know when creating an array if there is any reason why you choose one of the following over the others or if it is just a styling choice by the developer
    >
    > int productIDs[] = {10,20,30};
    > int []productIDs = {10,20,30};
    > int[] productIDs = {10,20,30};
    >
    > I did notice the the following will cause a compilation error
    > []int productIDs = {10,20,30}; //causes an error


    By java convention the standard is int[] productIDs = {10,20,30};
    the brackets must indicate the data type.The other way is also allowed but discourager.refer : http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html
     
    Arun GOPI, Jul 16, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alexandra Stehman
    Replies:
    5
    Views:
    30,659
    Chris Smith
    Jun 17, 2004
  2. Bill Reyn
    Replies:
    3
    Views:
    2,261
    Bob Hairgrove
    Jun 22, 2004
  3. Mantorok Redgormor

    initializing arrays of arrays

    Mantorok Redgormor, Sep 10, 2003, in forum: C Programming
    Replies:
    4
    Views:
    569
  4. kelvSYC

    Arrays and Pointers to Arrays

    kelvSYC, Sep 26, 2003, in forum: C Programming
    Replies:
    2
    Views:
    387
  5. Philipp
    Replies:
    21
    Views:
    1,134
    Philipp
    Jan 20, 2009
Loading...

Share This Page