Get the default value by type



  • A friend of mine got from a friend of him this snippet, that he asked me to post here:

    public Object getDefaultValue(String strType) {
      if(strType==null)
       return null;
      if(strType.equals("STRING"))
       return "";
      if(strType.equals("INTEGER"))
       return new Integer(0);
      if(strType.equals("FLOATING"))
       return new Float(0.0f);
      if(strType.equals("DATE") || strType.equals("TIMESTAMP"))
       return new java.util.Date();
      if(strType.equals("BOOLEAN"))
       return new Boolean(true);
      if(strType.equals("GUID"))
       return "";
      if(strType.equals("OBJECT"))
       return new Object();
      return null;
     }
    


  • A friend of mine, got from a cousin of a friend of a friend of him a comment for your post, but I forgot what it was. Sorry.



  •  TRWTF is java.util.Date. It's so goddamn useless.



  • So the WTF is the placement of the curly braces?



  • I get it--it'll fail if strType has lowercase letters! WTF!!??



  • @frits said:

    So the WTF is the placement of the curly braces?

    No, it's Java's lack of a useful switch statement.


  • @bstorer said:

    @frits said:

    So the WTF is the placement of the curly braces?

    No, it's Java's lack of a useful switch statement.

    Just crc32 the text and switch on the int, asshole.  Christ, you programmers have to make everything so difficult.



  • @bstorer said:

    Java's lack of a useful switch statement.
     

    What do you mean.

     

    Java doesn't have switch() { case "abc": } ?



  • @dhromed said:

    @bstorer said:

    Java's lack of a useful switch statement.
     

    What do you mean.

     

    Java doesn't have switch() { case "abc": } ?

    No.



  • @dhromed said:

    @bstorer said:

    Java's lack of a useful switch statement.
     

    What do you mean.

     

    Java doesn't have switch() { case "abc": } ?

     

    In Java, you can only switch on primitive types. (Strings are not primitives in Java.)

    Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.



  • @Someone You Know said:

    @dhromed said:

    @bstorer said:

    Java's lack of a useful switch statement.
     

    What do you mean.

     

    Java doesn't have switch() { case "abc": } ?

     

    In Java, you can only switch on primitive types. (Strings are not primitives in Java.)

    Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.

     

    But there's so much in Java that the designers didn't feel were worth the effort.  Making Java and Oracle a match made in heaven.



  • @morbiuswilters said:

    @bstorer said:

    @frits said:

    So the WTF is the placement of the curly braces?

    No, it's Java's lack of a useful switch statement.

    Just crc32 the text and switch on the int, asshole.  Christ, you programmers have to make everything so difficult.

    Man, do you sound like an idiot.  Just use a HashMap and map the strings to functors.


  • @Medezark said:

    @Someone You Know said:

    @dhromed said:

    @bstorer said:

    Java's lack of a useful switch statement.
     

    What do you mean.

     

    Java doesn't have switch() { case "abc": } ?

     

    In Java, you can only switch on primitive types. (Strings are not primitives in Java.)

    Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.

     

    But there's so much in Java that the designers didn't feel were worth the effort.  Making Java and Oracle a match made in heaven.

     

    Yeah, I never said it was a good idea. The distinction in Java between primitive types and object types is a constant source of WTFs.



  • @Medezark said:

    @Someone You Know said:

    In Java, you can only switch on primitive types. (Strings are not primitives in Java.)

    Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.

    But there's so much in Java that the designers didn't feel were worth the effort.  Making Java and Oracle a match made in heaven.
    It's not even that they thought it wasn't worth the effort.  I've always had the impression that it was a combination between a misplaced superiority that lead them to design a language without certain features For Your Own Good, and a bizzarre mindset equal parts academic and bureaucratic.


  • Trolleybus Mechanic

    @apetrelli said:

    A friend of mine got from a friend of him this snippet, that he asked me to post here:
     

    Yeah, I hear those voice, too.



  • @Lorne Kates said:

    A tinfoil hate cannot stop curses
    I can't believe no one pointed out yet that a friend of the OP's friend may well be the OP.



  • @Someone You Know said:

    In Java, you can only switch on primitive types. (Strings are not primitives in Java.)

     

    Will this old trick work?

     

    switch (1) {

      case foo == "bar": ...

      ...

    }

     



  • @emurphy said:

    @Someone You Know said:

    In Java, you can only switch on primitive types. (Strings are not primitives in Java.)

    Will this old trick work?

    switch (1) {

      case foo == "bar": ...

      ...

    }

    No, for a variety of reasons.


  •  @emurphy said:

    Will this old trick work?

    switch (1) {

      case foo == "bar": ...

      ...

    }

     

    <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 3.0 (Win32)"><style type="text/css"> </style>

    No, the case statement requires a constant, primitive integer (int) value. 


  • Trolleybus Mechanic

    @DeepThought said:

     @emurphy said:

    Will this old trick work?

    switch (1) {

      case foo == "bar": ...

      ...

    }

     

     

    No, the case statement requires a constant, primitive integer (int) value. 

     

     Yeah. The proper way is:

    int thecase = 0;
    if (foo == "bar")
      thecase = 1;
    elseif (foo == "frak")
      thecase = 2;

    switch(thecase)
      case 1: print "You entered bar";
      case 2: print "You entere frak":



  • @Lorne Kates said:

    @DeepThought said:

     @emurphy said:

    Will this old trick work?

    switch (1) {

      case foo == "bar": ...

      ...

    }

     

     

    No, the case statement requires a constant, primitive integer (int) value. 

     

     Yeah. The proper way is:

    int thecase = 0;
    if (foo == "bar")
      thecase = 1;
    elseif (foo == "frak")
      thecase = 2;

    switch(thecase)
      case 1: print "You entered bar";
      case 2: print "You entere frak":

    Obviously, this is the right way to do it:

    switch (foo.hashCode()) {
        case 97299: //bar
            System.out.println("You entered bar");
            break;
        case 3151350: //brak
            System.out.println("You entered brak");
            break;
        default:
            System.out.println("You entered nonsense.  Idiot.");
    }


  • @bstorer said:

    Obviously, this is the right way to do it:
    switch (foo.hashCode()) {
        case 97299: //bar
            System.out.println("You entered bar");
            break;
        case 3151350: //brak
            System.out.println("You entered brak");
            break;
        default:
            System.out.println("You entered nonsense.  Idiot.");
    }

     

     I suggest declaring and initializing the constant hash code values like this:

    public static final int BAR_HASH = "bar".hashCode();
    public static final int BRAK_HASH = "brak".hashCode(); 

     Then reference those "constant" references on the case statements. Of course, if you are concerned about making a case-insensitive comparison then you need to be sure to change the case on the String being tested to ensure it's all lower case (or upper case if that's how you initialized the hash code constants).

     

     



  • @DeepThought said:

    I suggest declaring and initializing the constant hash code values like this:

    public static final int BAR_HASH = "bar".hashCode();
    public static final int BRAK_HASH = "brak".hashCode(); 

    Shirley you mean <font face="courier new,courier">private</font>?

    Anyway, the correct way is using reflection, possibly with annotations.

    I just can't be bothered to implement this right now.



  • It must also be noted that there is no guarantee that the
    hashCode() method will return a unique value for every string
    permutation. This means that there is always the possibility that
    using a switch/case based on the hashCode will create anomalous
    results. The best methods in Java are to use if/elseif statements or
    as bstorer pointed out earlier use some sort of Map object to
    associate a known string value with an action class.



  • @DeepThought said:

    It must also be noted that there is no guarantee that the hashCode() method will return a unique value for every string permutation. This means that there is always the possibility that using a switch/case based on the hashCode will create anomalous results. The best methods in Java are to use if/elseif statements or as bstorer pointed out earlier use some sort of Map object to associate a known string value with an action class.

    Thank God you are here to be a shining beacon of reason.



  • @DeepThought said:

    @bstorer said:

    Obviously, this is the right way to do it:
    switch (foo.hashCode()) {
        case 97299: //bar
            System.out.println("You entered bar");
            break;
        case 3151350: //brak
            System.out.println("You entered brak");
            break;
        default:
            System.out.println("You entered nonsense.  Idiot.");
    }

     

     I suggest declaring and initializing the constant hash code values like this:

    public static final int BAR_HASH = "bar".hashCode();
    public static final int BRAK_HASH = "brak".hashCode(); 

     Then reference those "constant" references on the case statements. Of course, if you are concerned about making a case-insensitive comparison then you need to be sure to change the case on the String being tested to ensure it's all lower case (or upper case if that's how you initialized the hash code constants).

    Nuts to that.  Let's use an Enum!

    public static enum Switch { bar, brak }
    

    try {
    switch (Enum.valueOf(Switch.class, foo) {
    case bar:
    System.out.println("You entered bar");
    break;
    case brak:
    System.out.println("You entered brak");
    break;
    }
    }
    catch (IllegalArgumentException iae) {
    System.out.println("You entered nonsense. Idiot.");
    }



  • The use of private vs. public vs. default modifiers is really dependent upon the specifics of the implementation. After having far too much frustration in extending classes provided by a third party where all the needed properties/methods were hidden behind a private access modified making it impossible to extend the logic without completely rewriting it, I've tended to prefer using either the public or default access modifiers if there is no clear reason or dictate to hide the particulars of an implementation.

    Yes, reflection could be used if the strings being tested included only characters allowed in the naming of class or method. If not, then there needs to be some sort of translation to make the names legal (resulting in some ugly class or method names) or you will have to look at an alternative solution. Personally, I'm not a big advocate of reflection. It certainly has it's place and I've used it before, but I feel it should only be used when you really don't have a choice as it can circumvent compiler and even run-time optimizations not to mention making it difficult for other developers to identify dependencies. In the case of the method presented by the OP the use of reflection would seem to be overkill.

    Depending on how it's used, the method itself doesn't really seem to fall the level of a major WTF. It is missing else clauses making it's performance sub-optimal, but I can easily envision how a method such as the one presented by the OP could have a purpose in some sort of interpretor.



  • @DeepThought said:

    tl;dgas
    Good Lord.  Do you really think the rest of us are serious?



  •  I think you forgot the sarcasm tag.



  • @bstorer said:

    Good Lord.  Do you really think the rest of us are serious?

    Certainly not you, but I'm not really responding for your benifit. Rather I'm responding the poor bastards who will read your comments and take them seriously.



  • @DeepThought said:

    @bstorer said:

    Good Lord.  Do you really think the rest of us are serious?

    Certainly not you, but I'm not really responding for your benifit. Rather I'm responding the poor bastards who will read your comments and take them seriously.

    Thanks for ruining everything, asshole.



  • @morbiuswilters said:

    @DeepThought said:

    @bstorer said:

    Good Lord.  Do you really think the rest of us are serious?

    Certainly not you, but I'm not really responding for your benifit. Rather I'm responding the poor bastards who will read your comments and take them seriously.

    Thanks for ruining everything, asshole.

      Tell me about it.  In the spirit of William Randolph Hearst, instead of merely commenting on WTFs, we were trying to manufacture them.  How are we ever going to goad the US into a war with Spain now?


  • @bstorer said:

    @morbiuswilters said:

    @DeepThought said:

    @bstorer said:

    Good Lord.  Do you really think the rest of us are serious?

    Certainly not you, but I'm not really responding for your benifit. Rather I'm responding the poor bastards who will read your comments and take them seriously.

    Thanks for ruining everything, asshole.

      Tell me about it.  In the spirit of William Randolph Hearst, instead of merely commenting on WTFs, we were trying to manufacture them.  How are we ever going to goad the US into a war with Spain now?

    What if we tell people that the men of Spain like to suck dongs.  Like, a whole lot.  And they want to come to America and suck your dong.  And then teach your children about evolution.  Think that would do it?



  • @DeepThought said:

    It must also be noted that there is no guarantee that the hashCode() method will return a unique value for every string permutation. This means that there is always the possibility that using a switch/case based on the hashCode will create anomalous results. The best methods in Java are to use if/elseif statements or as bstorer pointed out earlier use some sort of Map object to associate a known string value with an action class.
     

    Can you imagine the gall of those posters?! Posting incorrect code on THIS of all websites! They should be more ashamed of themselves than usual.

    Thank you for coming in and saving us all, like a beacon of hope and freshly-cooked crisp bacon.



  • @morbiuswilters said:

    @bstorer said:

    @morbiuswilters said:

    @DeepThought said:

    @bstorer said:

    Good Lord.  Do you really think the rest of us are serious?

    Certainly not you, but I'm not really responding for your benifit. Rather I'm responding the poor bastards who will read your comments and take them seriously.

    Thanks for ruining everything, asshole.

      Tell me about it.  In the spirit of William Randolph Hearst, instead of merely commenting on WTFs, we were trying to manufacture them.  How are we ever going to goad the US into a war with Spain now?

    What if we tell people that the men of Spain like to suck dongs.  Like, a whole lot.  And they want to come to America and suck your dong.  And then teach your children about evolution.  Think that would do it?

    We've known all that for years; we'll have to be even more clever.  Dammit, this was so much easier in the 60s when you could just accuse them of being Communists and know the bombs were on the way.


  • @bstorer said:

    @morbiuswilters said:

    @bstorer said:

    @morbiuswilters said:

    @DeepThought said:

    @bstorer said:

    Good Lord.  Do you really think the rest of us are serious?

    Certainly not you, but I'm not really responding for your benifit. Rather I'm responding the poor bastards who will read your comments and take them seriously.

    Thanks for ruining everything, asshole.

      Tell me about it.  In the spirit of William Randolph Hearst, instead of merely commenting on WTFs, we were trying to manufacture them.  How are we ever going to goad the US into a war with Spain now?

    What if we tell people that the men of Spain like to suck dongs.  Like, a whole lot.  And they want to come to America and suck your dong.  And then teach your children about evolution.  Think that would do it?

    We've known all that for years; we'll have to be even more clever.  Dammit, this was so much easier in the 60s when you could just accuse them of being Communists and know the bombs were on the way.

    Well, now that we have a Communist President, why not just accuse them of being Capitalists?  Surely that's good enough for a napalm attack, if nothing else.



  • @morbiuswilters said:

    @bstorer said:

    @morbiuswilters said:

    @bstorer said:

    @morbiuswilters said:

    @DeepThought said:

    @bstorer said:

    Good Lord.  Do you really think the rest of us are serious?

    Certainly not you, but I'm not really responding for your benifit. Rather I'm responding the poor bastards who will read your comments and take them seriously.

    Thanks for ruining everything, asshole.

      Tell me about it.  In the spirit of William Randolph Hearst, instead of merely commenting on WTFs, we were trying to manufacture them.  How are we ever going to goad the US into a war with Spain now?

    What if we tell people that the men of Spain like to suck dongs.  Like, a whole lot.  And they want to come to America and suck your dong.  And then teach your children about evolution.  Think that would do it?

    We've known all that for years; we'll have to be even more clever.  Dammit, this was so much easier in the 60s when you could just accuse them of being Communists and know the bombs were on the way.

    Well, now that we have a Communist President, why not just accuse them of being Capitalists?  Surely that's good enough for a napalm attack, if nothing else.

    Maybe we can convince the terrorists that Spain is a symbol of capitalist Americanism and let them do the dirty work for us.  Then the UN will send the terrorists a strongly worded letter and everything will be fine.


  • @bstorer said:

    Maybe we can convince the terrorists that Spain is a symbol of capitalist Americanism and let them do the dirty work for us.

    Ha ha, we already did!  Remember Madrid?  No?  Well, I can't blame you.



  • @morbiuswilters said:

    @bstorer said:

    Maybe we can convince the terrorists that Spain is a symbol of capitalist Americanism and let them do the dirty work for us.

    Ha ha, we already did!  Remember Madrid?  No?  Well, I can't blame you.

    Yeah, but Madrid is still there; that's hardly good enough.  I mean, a few trains on fire?  I could've accomplished that by putting Amtrak in charge of their subway system.  We need something of larger scale to completely irradicate Spain for crimes which I'll come up with later.  Anything short of terrorists hijacking Madagascar and crashing it into Spain just doesn't impress me.


  •  I don't like Spain.

    It's too hot there.

    It'll be even worse when you napalm it, so that's not helping.

     

    Waste of all those dicks, though.  :((((



  • The REAL way to do it is this:

     

    switch((int)strType.charAt(0))

    {

    case 110: return null;break;

    case 71:

    case 83: return "";break;

    case 73: return new Integer(0);break;

    case 70: return new Float(0.0f);break;

    case 68:

    case 84: return new java.util.Date();break;

    case 66: return new Boolean(true);break;

    case 79: return new Object();break;

    default: return null;

    }


    TRWTF is the use of Float instead of Double, unless they've written their own math libraries, which is probably a NIHWTF in itself. And even then, they still have to deal with that silly 0.0f casting.


  • @JohnWestMinor said:

    switch((int)strType.charAt(0))

    {

    case 110: return null;break;

    case 71:

    case 83: return "";break;

    case 73: return new Integer(0);break;

    case 70: return new Float(0.0f);break;

    case 68:

    case 84: return new java.util.Date();break;

    case 66: return new Boolean(true);break;

    case 79: return new Object();break;

    default: return null; break;

    }

    FTFY. Gee, such an obvious mistake and you didn't get it?



  • @JohnWestMinor said:

    The REAL way to do it is this:

     

    switch((int)strType.charAt(0))

    {

    case 110: return null;break;

    case 71:

    case 83: return "";break;

    case 73: return new Integer(0);break;

    case 70: return new Float(0.0f);break;

    case 68:

    case 84: return new java.util.Date();break;

    case 66: return new Boolean(true);break;

    case 79: return new Object();break;

    default: return null;

    }


    TRWTF is the use of Float instead of Double, unless they've written their own math libraries, which is probably a NIHWTF in itself. And even then, they still have to deal with that silly 0.0f casting.

    Is the break really needed? The return will exit the method so it'll never get to the break right?



  • @XIU said:

    @JohnWestMinor said:

    The REAL way to do it is this:

     

    switch((int)strType.charAt(0))

    {

    case 110: return null;break;

    case 71:

    case 83: return "";break;

    case 73: return new Integer(0);break;

    case 70: return new Float(0.0f);break;

    case 68:

    case 84: return new java.util.Date();break;

    case 66: return new Boolean(true);break;

    case 79: return new Object();break;

    default: return null;

    }


    TRWTF is the use of Float instead of Double, unless they've written their own math libraries, which is probably a NIHWTF in itself. And even then, they still have to deal with that silly 0.0f casting.

    Is the break really needed? The return will exit the method so it'll never get to the break right?

     

    Correct. However, a lot of Java programmers have been taught to always put a break statement at the end of every case, to avoid potential bugs caused by falling through to the next case unintentionally. You occasionally meet people who think this is actually a requirement of the language.



  • @Someone You Know said:

    Correct. However, a lot of Java programmers have been taught to always put a break statement at the end of every case, to avoid potential bugs caused by falling through to the next case unintentionally. You occasionally meet people who think this is actually a requirement of the language.
     

    Visual Studio gripes at you if you leave off breaks in a switch statement in C#. I'm not sure if that's a C# language requirement, or just something VS bitches at you about.



  • @blakeyrat said:

    @Someone You Know said:

    Correct. However, a lot of Java programmers have been taught to always put a break statement at the end of every case, to avoid potential bugs caused by falling through to the next case unintentionally. You occasionally meet people who think this is actually a requirement of the language.
     

    Visual Studio gripes at you if you leave off breaks in a switch statement in C#. I'm not sure if that's a C# language requirement, or just something VS bitches at you about.

    Not if you use a return, because then it will complain because the break; code is unreachable.



  • @XIU said:

    Not if you use a return, because then it will complain because the break; code is unreachable.
     

    Gripes either way.

    If they're going to require break every time, they should optionally let you use curly braces instead. Quicker to type. (Of course, you still need break if you have two case conditions with the same code block... so I guess that doesn't work.)



  • @XIU said:

    @blakeyrat said:

    @Someone You Know said:

    Correct. However, a lot of Java programmers have been taught to always put a break statement at the end of every case, to avoid potential bugs caused by falling through to the next case unintentionally. You occasionally meet people who think this is actually a requirement of the language.
     

    Visual Studio gripes at you if you leave off breaks in a switch statement in C#. I'm not sure if that's a C# language requirement, or just something VS bitches at you about.

    Not if you use a return, because then it will complain because the break; code is unreachable.

     

    Yes, I forgot about the break;'s not being needed with return. I was too busy being clever with the ascii to think about what I was really doing. TRWTF is the vague and ambiguous code I post for humor not compiling. Or, rather, that the break;'s should be an issue at all, considering how much of a habit it becomes unless you intentionally want it to fall through, which I used a couple times.



  • @Someone You Know said:

    In Java, you can only switch on primitive types. (Strings are not primitives in Java.)

    Java's switch statements assign an integer constant to each case value, so that the whole thing can be optimized into a lookup table of instruction pointers. There is no obvious way to do this for a Java Object that will both a) always work the way you want it to and b) be faster than a series of if statements, especially if the runtime type of the object is not known at compile time. Thus, switching on an Object would just be syntactic sugar, which the language designers apparently felt was not worth the effort.

     

    Java 7 will have switching on strings.



  •  Y'know, you could also concatinate the ascii code for each character into one long string (with like a 6 character cutoff) and then turn those into a long, divide by a standard number to get it down to an int and then switch on that value.Of course, you would have false positives from similar strings, but that's a problem for the next developer.


Log in to reply