domenico's Profile User Rating: -----

Reputation: 0 Apprentice
Group:
Active Members
Active Posts:
89 (0.1 per day)
Joined:
21-July 12
Profile Views:
943
Last Active:
User is offline Jan 08 2014 07:57 AM
Currently:
Offline

Previous Fields

Dream Kudos:
0
Icon   domenico has not set their status

Posts I've Made

  1. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 6 Nov 2013

    Yeah, that was helpful. I really thank you for your explanation.
    It's a lot going on down there, but I can see it better now.
    Thinking about how the line public class Guitar extends Instrument and the kind of the relationship between this two object, has made the fact clearer for me.
    I like your analogies, keep the ideas more enduring.
    Thank you for not giving up on me after the 2134524th question on the same topic!
  2. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 6 Nov 2013

    View Postjjh08, on 05 November 2013 - 01:45 PM, said:

    The private method in Instrument is not seen by any other class period so you are correct and the polymorphism was never factored in because as Peter O said, the "hidden" play() method was called from within the Instrument class via the tune() method.
    To reiterate what I said in an earlier post, Guitar.main() calls Instrument.tune(). From that point, Instrument.tune() will call Instrument.play() and the output "Play Instrument" will be displayed.


    I follow you until that point, but why the Wind.play() method is not called here? It's public, so it should be visible from the Instrument class, it has the same name. I understand that if a method is private, then it can't be inherited by any of its subclasses, and maybe that's the reason it's not called here, but why was that behavior implemented?
    To clarify, I'm not talking about the inheritability of the private method, I'm talking about the Polymorphism not being factored in when the subclass method is a public one, with the name of a private method in the mother class.
    I am asking this, just because until now, I always found a really precise and specific reason for the not-so-immediate behavior that a language implements.
    What is the danger that the Java makers wanted its users to avoid implementing this behavior?
  3. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 6 Nov 2013

    View PostPeter O, on 06 November 2013 - 01:05 AM, said:

    View Postdomenico, on 05 November 2013 - 06:22 PM, said:

    View PostPeter O, on 05 November 2013 - 11:01 AM, said:

    I don't understand. Why can't you use final?

    That's exactly what I am asking :)/>/>/>
    Apparently, it's a Java rule. You can't restrict the modifier of an inherited method.
    public can't become private or final (I just checked this)

    Here is an example that shows how final can be used to prevent a method from being overridden.
    class A
    {
    	public void foo(){}
    }
    
    class B extends A
    {
    	final public void foo(){} // This compiles fine
    }
    
    class C extends B
    {
    	public void foo(){} // error: foo() in C cannot override foo() in B
    	                    // overridden method is final
    }
    

    Wow, I missed that one. Thank you for that ;)/>
  4. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 5 Nov 2013

    View PostPeter O, on 05 November 2013 - 11:01 AM, said:

    I don't understand. Why can't you use final?


    That's exactly what I am asking :)
    Apparently, it's a Java rule. You can't restrict the modifier of an inherited method.
    public can't become private or final (I just checked this)
  5. In Topic: Upcasting and little examples (that don't behave as expected)

    Posted 5 Nov 2013

    View Postjjh08, on 04 November 2013 - 10:04 PM, said:

    Hello domenico, I will try to explain this process to best of my knowledge but I am not an expert.

    Quote

    1) Guitar extends Instrument, so it has every Instrument method, without the private ones.

    I believe that this is correct.

    Quote

    2) public void play() in the Guitar class, is not an override, it's more a redefinition of the play method, since it was not inherited from the mother class (it has been defined private there)

    I believe this is also correct.

    Quote

    3) When I call Instrument.tune(Instrument i) upcasting happens and the Guitar is now an Instrument, but it references is still the one of the guitar object, that has the capability of public void play()'ing but that doesn't happens anymore.

    I believe what is happening at this point is that when static void tune(Instrument i) is called in main(), the key factor is not necessarily the 'guitar' reference but the method call itself. In other words, the Guitar child class calls tune() which belongs to the Instrument parent class (It also inherited tune() but this is irrelevant for our example). This tune() method will then call the "hidden" play() method which will output the original statement "Play Instrument".

    On the other hand, when the play() method of the Instrument class was public, as in your first example, the child class Guitar would inherit play() from its Parent class Instrument. So, in that case, when you call tune() in main(), the compiler/JVM (not sure which one or both) will still go through the process of checking the Parent class play() method. However, the compiler/JVM (whichever one??) sees that you inserted a 'guitar' reference within tune() and a process called late binding/dynamic binding will occur which means that the Guitar's play() method will be displayed in the output at runtime which would be "Play Guitar".
    I hope our experts can chime in and verify this information but I believe it is correct if I remember correctly.

    Quote

    4) The private method inside of the mother class is called, and all the things I ever thought I learned about upcasting are gone, abruptly smashed to death.

    No, those private methods definitely were not accessed by the child class so you were originally correct.

    As for your pseudo-code:
     if (staticTypeMethod.isPrivate()) {
      staticTypeMethod();
    else {
      if (dynamicTypeMethodExists) {
        dynamicTypeMethod()
      } else {
        staticTypeMethod()
      }
    }
    

    I don't think it matters if the method is static or dynamic but I could be wrong.
    In the example below, I basically just removed the static keyword from the tune() method and we still see the same result unless I'm not understanding your second post correctly.
    class Instrument2 {
    	private void play() {
    		System.out.println("Play Instrument2");
    	}
    	
    	void tune(Instrument2 i2) {
    		i2.play();
    	}
    }
    
    public class Guitar2 extends Instrument2 {
    	public void play() {
    		System.out.println("Play Guitar2");
    	}
    	
    	public static void main(String[] args) {
    		Instrument2 instrument2 = new Instrument2();
    		Guitar2 guitar2 = new Guitar2();
    		instrument2.tune(guitar2);
    	}
    }
    

    Anyway I hope my information will be able to help you :)


    Sorry about the static or dynamic methods, I started to talk about static type and dynamic type and mixed up the two things.
    Anyway, I still don't understand the mechanism.
    When al the methods were public, all went as expected.
    When the play() method was made private in the Instrument class, it would make more sense to me to launch an exception and go away. After all, I shouldn't know about the private methods of a class. If I call them from a subclass, and the Polymorphism in not effective, why would they run anyway? Isn't this a generally unexpected behavior?
    Maybe there is an advantage I can't see here, is that right? What's the other side of the coin?
    I would try the case where the mother class is public and the subclass method is private, but the compiler would blame me, because can't assign weaker privilege to an inherited method, so no more fun here :)

    I would like to enrich the discussion and go ahead though. In some cases, I would like to make a class that has the capabilities of another class, but I want to change the behavior of a method and don't want to let the user modify it, if they want to use my class (I would make the inherited public method a final one). Why I can't do that? What's the other side, the gain in forbidding this behavior?

    Thank you for replying all my question. It's so good to me to just talk about this things.
    I just entered the Java world and I'd love to know its philosophy, understand the logic behind, before making something big.

My Information

Member Title:
D.I.C Head
Age:
Age Unknown
Birthday:
Birthday Unknown
Gender:

Contact Information

E-mail:
Private

Friends

domenico hasn't added any friends yet.

Comments

domenico has no profile comments yet. Why not say hello?