Forum Stats

  • 3,760,212 Users
  • 2,251,664 Discussions
  • 7,871,021 Comments

Discussions

Typed collection and method overloading

843793
843793 Member Posts: 41,732 Green Ribbon
edited May 19, 2010 12:42PM in Generics
With generics collections are now typed safe. so why following is not legal

class Test {
private void myMethod(List<Number> l) {}

private void myMethod(List<String> l) {}
}


I have 2 different flavour of method in same class with different Type of collection. I should allows to overload
«1

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    The problem is type erasure (google it for an extensive explanation).

    At runtime there is no information if any given List is a List<Number> or a List<String>, they are both considered to be simply "List". Therefore there's no way to distinguish those two methods at runtime.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    agreed that method overloading is at Object type level and I can not have 2 method with same object type in a class.
    But with generics java should allowed it. and there should be some mechanism at run time also to bound typed collection
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    hkachoria wrote:
    But with generics java should allowed it.
    But it doesn't.

    What are you trying to say? "should" means almost nothing.
    and there should be some mechanism at run time also to bound typed collection
    What do you mean by "bound"?
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    OK I should improve my should :)
    With generics I thought that I can have overloading with different type of collection and based on the type I can have return type (same type)
    so when I start writing this compiler complain about this.

    Bound means in my word, if I have typed collection then collection is bound to accept object of that particular type. It’s same as any declaration.
    As per Java doc "Overloaded methods are differentiated by the number and the type of the arguments passed into the method"

    And we have collection of different types then why I'm not allowed to overload a collection with different types.
    I hope I'm quite reasonable :)
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    hkachoria wrote:
    With generics I thought that I can have overloading with different type of collection
    Which turned out to be false.
    and based on the type I can have return type (same type)
    You can have the return type depend on the argument type by using a type parameter on your method, but that only works with a single method.
    so when I start writing this compiler complain about this.
    Because it doesn't work as you thought it would.
    Bound means in my word, if I have typed collection then collection is bound to accept object of that particular type. It&#146;s same as any declaration.
    You can use the Collections.checked*() methods to produce a collection that actually does the type checks at runtime, if you whish.
    As per Java doc "Overloaded methods are differentiated by the number and the type of the arguments passed into the method"
    That's from one of the very first tutorials and therefore somehow oversimplifies things (which is necessary in order to not crush beginners with tons of technical jargon and details).

    Read what [the JLS has to say on the topic of method signatures|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#38649]. Signatures are what uniquely identifies a method. Therefore you can't have to methods with the same signature or override-equivalent signatures in one class.
    And we have collection of different types then why I'm not allowed to overload a collection with different types.
    Because the signatures of your two methods are override-equivalent.
    I hope I'm quite reasonable :)
    I don't know, exactly. The idea that this could work is reasonable. But I told you that it doesn't work. If you still insist that it works or that it must work, then that's being unreasonable.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    OK :)
    I will not insist but do you know why during design of generics this idea was not considered?
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    hkachoria wrote:
    do you know why during design of generics this idea was not considered?
    I'm very, very sure that it was considered, they considered a lot of things when designing generics.

    The reason why type erasure was chosen as the way to implement generics (which directly results in the restriction you see now) is that it was the most viable solution that provided very, very good backwards-compatibility both on the binary level (.class files both with and without generics can be mixed) and at the source files (old code could incrementally be enhanced with generics). Java has traditionally had a very strong focus on backwards-compatibility and any solution that didn't provide that wouldn't have bee accepted by a big part of the community.

    Compare that with the way generics are implemented in C#, where a List[Foo] is a very different type than a List. They broke backwards compatibility (which is not necessarily a bad thing, it just shows that they had different design goals) and therefore could implement a more powerful version of that concept. For example .NET supports value-types (primitive types would be the closes equivalent in Java, but that's only telling halve the story) as type parameters and actually produces specialized code that can optimize on that fact.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Thanks, so I can say everything should not be served in one plate it's step by step :) (may be we can have this feature in future......)
    Thanks for your answer
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    hkachoria wrote:
    (may be we can have this feature in future......)
    There are some small steps in the direction. If you're interested in it, the you should google for "reified generics java".

    It's definitely not in Java 7, however.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Joachim, hope you have a good answer for this because it drives me crazy:

    I have the following:
    public class MenuPage
        private OrderableIngredient getIngredientFromLookup(ArrayList<OrderableIngredient> items, String key){
    	...
        }
    
        private OrderedIngredient getIngredientFromLookup(ArrayList<OrderedIngredient> items, String key){
    	...
        }
    }
    So what's that? I think nothing extremely different than the initial poster's example; only names change and the return types, which -as far as I know- are not used in method calling on runtime. The problem with this is that actually IT WORKS!!! Netbeans complains about it but java compiler has no problem. What is going on here? Do I miss something? Does the return type make some difference? Every suggestion is wellcomed.

    Oh and by the way plz don't ask me for SSCCE since this is company code in a huge project. Thanks in advance.
This discussion has been closed.