Forum Stats

  • 3,855,522 Users
  • 2,264,515 Discussions
  • 7,906,030 Comments

Discussions

Generics and primitives

843793
843793 Member Posts: 41,732 Green Ribbon
edited May 15, 2003 2:59PM in Generics
I have looked around if we would be able to do this:

ArrayList<int> list = new ArrayList<int>();

Does anybody know if we would be able to use it for primitives? I found that they were considering it some time ago but that is all I could pick up.

Thank you
«1

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    The current proposal does not allow primitives to be used in this way.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon

    Well, they are suggesting an autoboxing implementation.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Thank you for the info.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    >
    Well, they are suggesting an autoboxing
    implementation.
    But neither the generics proposal nor the auto-boxing proposal specify the impact of auto-boxing on generics.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    With generics and auto-boxing you will be able to do something like this:

    ArrayList<Integer> list = new ArrayList<Integer>();

    list.add(5);
    list.add(new Integer(5));

    int x = list.get(0).intValue();

    The two add statements will have exactly the same effect. As auto-unboxing is not being proposed, the intValue() call will be required.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I was thinking of a case like this:
    public class X {
      private static <T> T f(T t) { return t; }
    
      public static void main(String[] args) {
         f(5); 
      }
    }
    If I called <Integer>f(5) then the int argument would be converted to the required Integer parameter using an autoboxing conversion.

    But how about f(5), where the compiler must perform parameter inference and argument conversion? Is it defined whether it's legal or illegal?
  • 843793
    843793 Member Posts: 41,732 Green Ribbon

    I don't know if I'm reading too much into this, but
    http://java.sun.com/features/2003/05/bloch_qa.html mentions:

    <em>
    Autoboxing/unboxing - Eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer).
    </em>

    Which seems to indicate that unboxing will be available in some form.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I don't know if I'm reading too much into this...
    No, you're not reading too much into it. One code sample contains the statement
    m.put(word, m.get(word) + 1);
    which demonstrates both autoboxing and autounboxing in one expression.

    The only open question is what is the int equivalent of null -- is it 0 or should it throw NullPointerException? I suppose the double equivalent could be 0, NaN, or NullPointerException.

    The beauty of having null represent 0 is that the code to count words does not need to handle the first occurrance of the word as a special case as in
    m.put(word, (m.get(word) == null ? 0 : m.get(word)) + 1);
    If Java supported operator overloading, we could further simplify it to
    m[word]++;
    exactly as you would write in C++ and similar to what you would write in Perl. The point is not to blindly put features from other languages into Java, but to make Java more expressive, or as Josh Bloch puts it, to "take some common idiom and provide linguistic support for it."
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    The beauty of having null represent 0 is that the code to count words does not need to handle the first occurrance of the word as a special case

    The problem, in the general case, is that there isn't any way to detect that the original number was null, if 0 is a valid range for that number. You'd have to go back to accepting an object type and de-wrapping manually. IMHO, you'd just be better off with a null-pointer exception. If you want null to actually translate to a valid primitive, then you should just check for it explicitly before hand.

    That seems the least surprising to me, anyway.

    God bless,
    -Toby Reyelts

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    there isn't any way to detect that the original number was null
    I agree. To some degree, backward compatiblity of libraries may suffer if
    null represents 0.

This discussion has been closed.