help in method overloading

Discussion in 'Java' started by frank, Nov 28, 2008.

  1. frank

    frank Guest

    public void show(Object o)
    {
    System.out.println("object");
    }

    public void show(String s)
    {
    System.out.println("String");
    }


    In main Method,


    obj.show(null);


    It will print "String".

    Please give the Explanation for that

    Thanks in Advance.
    frank, Nov 28, 2008
    #1
    1. Advertising

  2. On Nov 28, 12:27 am, frank <> wrote:
    > public void show(Object o)
    > {
    >   System.out.println("object");
    >
    > }
    >
    > public void show(String s)
    > {
    >   System.out.println("String");
    >
    > }
    >
    > In main Method,
    >
    > obj.show(null);
    >
    > It will print  "String".


    In the case of multiple overloads that match the arguments' static
    types, the compiler will attempt to choose the "most specific"
    overload - that is, the overload with the arguments furthest from
    Object. In your example, String is more specific than Object, but if
    you added a third overload

    public void show (Integer i) {
    System.out.println ("Integer");
    }

    the compiler would have two "most specific" overloads and would throw
    an error.

    -o
    Owen Jacobson, Nov 28, 2008
    #2
    1. Advertising

  3. frank

    frank Guest

    On Nov 28, 11:08 am, Owen Jacobson <> wrote:
    > On Nov 28, 12:27 am, frank <> wrote:
    >
    >
    >
    > > public void show(Object o)
    > > {
    > >   System.out.println("object");

    >
    > > }

    >
    > > public void show(String s)
    > > {
    > >   System.out.println("String");

    >
    > > }

    >
    > > In main Method,

    >
    > > obj.show(null);

    >
    > > It will print  "String".

    >
    > In the case of multiple overloads that match the arguments' static
    > types, the compiler will attempt to choose the "most specific"
    > overload - that is, the overload with the arguments furthest from
    > Object. In your example, String is more specific than Object, but if
    > you added a third overload
    >
    >   public void show (Integer i) {
    >     System.out.println ("Integer");
    >   }
    >
    > the compiler would have two "most specific" overloads and would throw
    > an error.
    >
    > -o


    Thank You Very Much
    frank, Nov 28, 2008
    #3
  4. frank

    Tom Anderson Guest

    On Thu, 27 Nov 2008, Owen Jacobson wrote:

    > On Nov 28, 12:27 am, frank <> wrote:
    >> public void show(Object o)
    >> {
    >>   System.out.println("object");
    >>
    >> }
    >>
    >> public void show(String s)
    >> {
    >>   System.out.println("String");
    >>
    >> }
    >>
    >> In main Method,
    >>
    >> obj.show(null);
    >>
    >> It will print  "String".

    >
    > In the case of multiple overloads that match the arguments' static
    > types, the compiler will attempt to choose the "most specific"
    > overload - that is, the overload with the arguments furthest from
    > Object. In your example, String is more specific than Object,


    That's right, but in the case of literal null as an argument, it does seem
    really counterintuitive. Personally, i'd prefer it if the compiler treated
    this situation as an error, as in the case where you also have an Integer
    (or whatever) version.

    > but if you added a third overload
    >
    > public void show (Integer i) {
    > System.out.println ("Integer");
    > }
    >
    > the compiler would have two "most specific" overloads and would throw
    > an error.


    tom

    --
    Would you like to remember more?
    Tom Anderson, Nov 28, 2008
    #4
  5. frank

    Daniel Pitts Guest

    Owen Jacobson wrote:
    > On Nov 28, 12:27 am, frank <> wrote:
    >> public void show(Object o)
    >> {
    >> System.out.println("object");
    >>
    >> }
    >>
    >> public void show(String s)
    >> {
    >> System.out.println("String");
    >>
    >> }
    >>
    >> In main Method,
    >>
    >> obj.show(null);
    >>
    >> It will print "String".

    >
    > In the case of multiple overloads that match the arguments' static
    > types, the compiler will attempt to choose the "most specific"
    > overload - that is, the overload with the arguments furthest from
    > Object. In your example, String is more specific than Object, but if
    > you added a third overload
    >
    > public void show (Integer i) {
    > System.out.println ("Integer");
    > }
    >
    > the compiler would have two "most specific" overloads and would throw
    > an error.
    >
    > -o


    This is also somewhat esoteric. I've been programming in Java for years,
    and I didn't know that :). For *most* cases, its better not to use
    overloading, but instead use similarly named methods that describe there
    differences, for example:

    public void showObject(Object o) { System.out.println("Object"); }
    public void showString(String s) { System.out.println("String"); }

    I would say the primary exception is when the input will be treated
    exactly the same regardless of type (println for example), in which case
    each overload should take an Object, or any type of primitive.


    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Dec 1, 2008
    #5
  6. frank

    Patel Guest

    On Dec 1, 8:19 am, Daniel Pitts
    <> wrote:
    > Owen Jacobson wrote:
    > > On Nov 28, 12:27 am, frank <> wrote:
    > >> public void show(Object o)
    > >> {
    > >>   System.out.println("object");

    >
    > >> }

    >
    > >> public void show(String s)
    > >> {
    > >>   System.out.println("String");

    >
    > >> }

    >
    > >> In main Method,

    >
    > >> obj.show(null);

    >
    > >> It will print  "String".

    >
    > > In the case of multiple overloads that match the arguments' static
    > > types, the compiler will attempt to choose the "most specific"
    > > overload - that is, the overload with the arguments furthest from
    > > Object. In your example, String is more specific than Object, but if
    > > you added a third overload

    >
    > >   public void show (Integer i) {
    > >     System.out.println ("Integer");
    > >   }

    >
    > > the compiler would have two "most specific" overloads and would throw
    > > an error.

    >
    > > -o

    >
    > This is also somewhat esoteric. I've been programming in Java for years,
    > and I didn't know that :).  For *most* cases, its better not to use
    > overloading, but instead use similarly named methods that describe there
    > differences, for example:
    >
    > public void showObject(Object o) { System.out.println("Object"); }
    > public void showString(String s) { System.out.println("String"); }
    >
    > I would say the primary exception is when the input will be treated
    > exactly the same regardless of type (println for example), in which case
    > each overload should take an Object, or any type of primitive.
    >
    > --
    > Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>


    Here "null" can be assigned to String, so when you have overloaded
    methods , compiler searches for matching(specific) method first, in
    this case first preference to the method which has String as an
    argument. Object is generic(base class for all other classes) so when
    there is no match "show(Object o)" will be called.

    [Note]: Object class is the root class, so when there is no match ,
    when all possibilities failed , method will be called which has
    argument of type Object(final option).
    Ex: Switch cases and the default. when all cases failed , default
    block will be executed.

    Thanks,
    Patel.
    Patel, Dec 2, 2008
    #6
  7. frank

    Daniel Pitts Guest

    Patel wrote:
    > On Dec 1, 8:19 am, Daniel Pitts
    > <> wrote:
    >> This is also somewhat esoteric. I've been programming in Java for years,
    >> and I didn't know that :). For *most* cases, its better not to use
    >> overloading, but instead use similarly named methods that describe there
    >> differences, for example:
    >>
    >> public void showObject(Object o) { System.out.println("Object"); }
    >> public void showString(String s) { System.out.println("String"); }
    >>
    >> I would say the primary exception is when the input will be treated
    >> exactly the same regardless of type (println for example), in which case
    >> each overload should take an Object, or any type of primitive.
    >>
    >> --
    >> Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

    >
    > Here "null" can be assigned to String, so when you have overloaded
    > methods , compiler searches for matching(specific) method first, in
    > this case first preference to the method which has String as an
    > argument. Object is generic(base class for all other classes) so when
    > there is no match "show(Object o)" will be called.
    >
    > [Note]: Object class is the root class, so when there is no match ,
    > when all possibilities failed , method will be called which has
    > argument of type Object(final option).
    > Ex: Switch cases and the default. when all cases failed , default
    > block will be executed.
    >
    > Thanks,
    > Patel.

    Were you actually replying to me, because I don't see how your response
    makes sense to my message. Overloading resolution is at compile time,
    so even if you have a "String" reference that is null, the reference
    type is String, so the overload will be chosen based on that type. When
    one needs to pass null to a particular overload that is ambiguous, it is
    common to actually cast the null to the specific type, for example
    show((Object)null);

    The need to do this is the sign of either a poorly-design or a mis-used API.

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Dec 2, 2008
    #7
  8. frank

    Lew Guest

    Daniel Pitts wrote:
    >>> ... For *most* cases, its better not to use
    >>> overloading, but instead use similarly named methods that describe there
    >>> differences, for example:
    >>>
    >>> public void showObject(Object o) { System.out.println("Object"); }
    >>> public void showString(String s) { System.out.println("String"); }

    ....
    > Overloading resolution is at compile time,
    > so even if you have a "String" reference that is null, the reference
    > type is String, so the overload will be chosen based on that type.  When
    > one needs to pass null to a particular overload that is ambiguous, it is
    > common to actually cast the null to the specific type, for example
    > show((Object)null);
    >
    > The need to do this is the sign of either a poorly-design or a mis-used API.


    Daniel's points are consistent with Joshua Bloch's advice in /
    Effective Java/ to "se overloading judiciously".

    --
    Lew
    Lew, Dec 2, 2008
    #8
    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. Iyer, Prasad C

    Overloading __init__ & Function overloading

    Iyer, Prasad C, Sep 30, 2005, in forum: Python
    Replies:
    3
    Views:
    6,392
    Fredrik Lundh
    Sep 30, 2005
  2. Fredrik Lundh
    Replies:
    0
    Views:
    431
    Fredrik Lundh
    Sep 30, 2005
  3. Steve Holden
    Replies:
    0
    Views:
    419
    Steve Holden
    Sep 30, 2005
  4. Iyer, Prasad C
    Replies:
    4
    Views:
    563
    John J. Lee
    Sep 30, 2005
  5. Fredrik Lundh
    Replies:
    0
    Views:
    384
    Fredrik Lundh
    Sep 30, 2005
Loading...

Share This Page