Forum Stats

  • 3,873,267 Users
  • 2,266,528 Discussions
  • 7,911,489 Comments

Discussions

Generic solution

13

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Yes thats my point. I think I mentioned in this thread or another one that I would use then if they were here, now that I understand them. Yes, my programs are filled with Collections returning Objects...

    But now i just realized it will kind of add a new ability. Casting will create smaller files than if you did the proper Wrapping. I cast now. Less memory is used with casting. smaller file sizes. But wrapping is safer albeit larger and uses more memory.

    But generics gives you the filesize and memory usage, and speed of writing code, of the casting method with the safety of the wrapping method. I am liking it more and more the more I read this forum.

    So even people today who wrap will be encouraged to unwrap and use the Generics.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon

    It seems that the role of generics is the same as the role of covariance -- type-safety. The casts in GJ will still be there, but they will be safe and will only occur in the bytecode. I hope nobody in their right mind will ever program separate LIST_OF_BOOKS etc. But I have some use-cases where it actually makes sense! For example a list of integers and other numeric types, with methods such as `sum�, `min� and `max�.

    An interesting question is what the chances are of Java including covariance in 1.5 -- its perfectly in line with the way generics will be implemented in javac it seems, so it would be nice to have as well.

    Last but not least, we could perhaps have a variant syntax, like this:
    x: Integer
    
    f (x: Integer): Integer
    with operator overriding added code would really start to look extremely readable:
    infix "+" (other: like this): like this
    One can always hope. :)

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I have been known to make a ThingySet, but only because I needed to do some extra wierd stuff to it.

    Covariance is, to the best of my knowledge, coming in at the same time as generics - hopefully 1.5 . Can't wait.
    f (x: Integer): Integer
    Erm... that's interesting, but it's definitely not Java. Until we have a system that lets you display the same code in a variety of syntaces (sp?), this is never going to be an option.

    Besides, don't forget Larry Wall's First Rule of Language Design: Everyone wants the colon
    Go look at Perl, including the in-development Perl 6. I think you'd like it.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I thought covariance had some OO issues people didnt like. perhaps its worthy of its own thread for discussion?

    I don't think it had nearly as many votes as Generics, and I don't recall any targeted implementations by Sun.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I thought covariance had some OO issues people didn't like.
    I can't think of any reason why covariance of return type isn't desirable. What are the issues you refer to?

    Perhaps it's worthy of its own thread for discussion?
    I think it's a no-brainer. Generic Java has always supported covariance of return type, and like generics, this feature reduces the number of casts needed in Java programs.

    I don't think it had nearly as many votes as Generics,
    and I don't recall any targeted implementations by Sun.
    Generics and Covariance were the #1 and #2 RFEs until the Memory Use Problem RFE recently became popular. Now Covariance is #3. It doesn't seem like it would be a good idea to remove covariance from Generic Java at this point because so many Java programmers are requesting it.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I was not aware the covariance was part of Generic Java. Since you know about the RFE I assume you know the discussion that went on in the REF thread and the comments in there. Not all were in favor and many had explanations on their positions.

    I don't know enough about it to have a position, im just citing what I saw in the thread.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    There were two issues in that thread on covariance. One was whether changes in the JVM were necessary to support covariant returns. Evidentally no change is required for this.
    The other issue was over another type of covariance --- that of parameter types. While covariant returns were generally considered safe and uncontroversial, covariant parameters are another matter altogether (and are not proposed for Java).
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Right, many people were somehow convinced that a JVM change was proposed to support covariant types. The Generic Java compiler handles covariance of return type without a JVM change, so this is not an issue.

    Changing method parameters to be contravariant would completely change the behavior of Java programs -- many overloading methods would suddenly become overriding methods. But this is completely different from making return types covariant, so again this is not an issue.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Covariance is not just covariant return types, that's why I used the term covariance -- so it is not, in fact, a no brainer, but I admit, I didn't know covariant return types was in GJ; I naively assumed that such things would be in another spec.

  • brucechapman
    brucechapman Member Posts: 466
    In my apps, even using 'int' or 'long'
    as generic integer is not acceptable, as I'm handling
    up to hundered millions integers which using 'byte'
    could save lots of memory usage. I could implement a
    set of 'Collection' classes for each primative type,
    however, it still takes lots time, and write the same
    logic again and again and again and again. I really
    want something like:
    HashMap<short, String> map = new HashMap();
    so that millions operations of
    map.put(5, "Value 5");
    could save lots of memory and CPU times compare with
    map.put(new Short(5), "Value 5");
    how about
    String[Short.MAXVALUE] map;
    map[5]="Value 5";
    and it doesn't use any space to store the key, only the value :)
This discussion has been closed.