Non-virtual methods - why?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Adrian Herscu

    Non-virtual methods - why?

    Hi all,

    In which circumstances it is appropriate to declare methods as non-virtual?

    Thanx,
    Adrian.


  • Daniel O'Connell

    #2
    Re: Non-virtual methods - why?


    "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
    news:%23yqf0Qug DHA.2352@TK2MSF TNGP09.phx.gbl. ..[color=blue]
    > Hi all,
    >
    > In which circumstances it is appropriate to declare methods as[/color]
    non-virtual?
    Any time that a) security could be comprimised, b)stability could be
    comprimised, c) its not possible to write a method that cannot be overriden
    safely(related to a &b both).[color=blue]
    >
    > Thanx,
    > Adrian.
    >
    >[/color]


    Comment

    • Daniel O'Connell

      #3
      Re: Non-virtual methods - why?


      "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
      news:%23yqf0Qug DHA.2352@TK2MSF TNGP09.phx.gbl. ..[color=blue]
      > Hi all,
      >
      > In which circumstances it is appropriate to declare methods as[/color]
      non-virtual?
      Any time that a) security could be comprimised, b)stability could be
      comprimised, c) its not possible to write a method that cannot be overriden
      safely(related to a &b both).[color=blue]
      >
      > Thanx,
      > Adrian.
      >
      >[/color]


      Comment

      • Horatiu Ripa

        #4
        Re: Non-virtual methods - why?

        Anytime you want that the base class method to remain unchanged by
        overwriting it in inheritors.
        :) I presume you came from Java where all the methods are virtual by
        default, anyway it adds some clarity to the code.

        --
        Horatiu Ripa

        "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
        news:#yqf0QugDH A.2352@TK2MSFTN GP09.phx.gbl...[color=blue]
        > Hi all,
        >
        > In which circumstances it is appropriate to declare methods as[/color]
        non-virtual?[color=blue]
        >
        > Thanx,
        > Adrian.
        >
        >[/color]


        Comment

        • Horatiu Ripa

          #5
          Re: Non-virtual methods - why?

          Anytime you want that the base class method to remain unchanged by
          overwriting it in inheritors.
          :) I presume you came from Java where all the methods are virtual by
          default, anyway it adds some clarity to the code.

          --
          Horatiu Ripa

          "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
          news:#yqf0QugDH A.2352@TK2MSFTN GP09.phx.gbl...[color=blue]
          > Hi all,
          >
          > In which circumstances it is appropriate to declare methods as[/color]
          non-virtual?[color=blue]
          >
          > Thanx,
          > Adrian.
          >
          >[/color]


          Comment

          • Jon Skeet

            #6
            Re: Non-virtual methods - why?

            Adrian Herscu <bmf1972@hotmai l.com> wrote:[color=blue]
            > In which circumstances it is appropriate to declare methods as non-virtual?[/color]

            Well, they're non-virtual by default, normally. The only time when you
            need to make them specifically non-virtual is when you're overriding a
            virtual method, but you don't want anyone to override your
            implementation.

            --
            Jon Skeet - <skeet@pobox.co m>
            Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.

            If replying to the group, please do not mail me too

            Comment

            • Adrian Herscu

              #7
              Re: Non-virtual methods - why?


              "Horatiu Ripa" <unreal@busines sco.us> wrote in message
              news:ewOUBXzgDH A.944@TK2MSFTNG P11.phx.gbl...[color=blue]
              > Anytime you want that the base class method to remain unchanged by
              > overwriting it in inheritors.
              > :) I presume you came from Java where all the methods are virtual by
              > default, anyway it adds some clarity to the code.
              >
              > --
              > Horatiu Ripa
              >[/color]

              You almost guess it right! I learn Java a few days before, and it says that
              it is C++ cleaned up. As far as I remember, C++ has virtual and non-virtual
              method declarations and now I see that C# continued that tradition. But, I
              want to understand the essence of it - why non-virtual methods are needed?
              Java is used almost ten years without non-virtual methods and nobody
              complains about!
              [color=blue]
              > "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
              > news:#yqf0QugDH A.2352@TK2MSFTN GP09.phx.gbl...[color=green]
              > > Hi all,
              > >
              > > In which circumstances it is appropriate to declare methods as[/color]
              > non-virtual?[color=green]
              > >
              > > Thanx,
              > > Adrian.
              > >
              > >[/color]
              >
              >[/color]


              Comment

              • Jon Skeet

                #8
                Re: Non-virtual methods - why?

                Adrian Herscu <bmf1972@hotmai l.com> wrote:[color=blue]
                > You almost guess it right! I learn Java a few days before, and it says that
                > it is C++ cleaned up. As far as I remember, C++ has virtual and non-virtual
                > method declarations and now I see that C# continued that tradition. But, I
                > want to understand the essence of it - why non-virtual methods are needed?
                > Java is used almost ten years without non-virtual methods and nobody
                > complains about![/color]

                Java *does* have non-virtual methods (they're called final in Java).
                Look at Object.wait() for example.

                --
                Jon Skeet - <skeet@pobox.co m>
                Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.

                If replying to the group, please do not mail me too

                Comment

                • andrew queisser

                  #9
                  Re: Non-virtual methods - why?

                  One common use is with the "Template Method" pattern:
                  the base class declares a public non-virtual function which
                  checks preconditions, calls a protected or private virtual
                  function, then checks postconditions, like so:

                  (F is non-virtual, DoF is protected virtual and probably abstract)

                  int base::F(int i)
                  {
                  int ret;
                  if (IsParamInRange (i))
                  ret = DoF(i);
                  if (IsRetInRange(r et))
                  return ret;
                  else
                  return someError;
                  }

                  The idea is to force everyone to use a common "entry point"
                  to some functionality with derived classes implementing specific
                  tasks.

                  Andrew

                  "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
                  news:%23yqf0Qug DHA.2352@TK2MSF TNGP09.phx.gbl. ..[color=blue]
                  > Hi all,
                  >
                  > In which circumstances it is appropriate to declare methods as[/color]
                  non-virtual?[color=blue]
                  >
                  > Thanx,
                  > Adrian.
                  >
                  >[/color]


                  Comment

                  • Adrian Herscu

                    #10
                    Re: Non-virtual methods - why?


                    "Jon Skeet" <skeet@pobox.co m> wrote in message
                    news:MPG.19dd23 d691eec69098975 b@news.microsof t.com...[color=blue]
                    > Adrian Herscu <bmf1972@hotmai l.com> wrote:[color=green]
                    > > You almost guess it right! I learn Java a few days before, and it says[/color][/color]
                    that[color=blue][color=green]
                    > > it is C++ cleaned up. As far as I remember, C++ has virtual and[/color][/color]
                    non-virtual[color=blue][color=green]
                    > > method declarations and now I see that C# continued that tradition. But,[/color][/color]
                    I[color=blue][color=green]
                    > > want to understand the essence of it - why non-virtual methods are[/color][/color]
                    needed?[color=blue][color=green]
                    > > Java is used almost ten years without non-virtual methods and nobody
                    > > complains about![/color]
                    >
                    > Java *does* have non-virtual methods (they're called final in Java).
                    > Look at Object.wait() for example.
                    >[/color]

                    I think you are wrong. Read the Java Language Specification, para 8.4.3.3:
                    "A method can be declared final to prevent subclasses from overriding or
                    hiding it. It is a compile-time error to attempt to override or hide a final
                    method".

                    A final method in Java is close to a sealed method in C# - it prevents
                    further overriding.
                    In Java, methods can be hidden only by static methods - so, Java has no
                    concept of non-virtual methods.
                    While in C#, methods can be hidden because they were not marked virtual -
                    so, in order to be sealed a method has to be virtual.
                    [color=blue]
                    > --
                    > Jon Skeet - <skeet@pobox.co m>
                    > http://www.pobox.com/~skeet
                    > If replying to the group, please do not mail me too[/color]


                    Comment

                    • Adrian Herscu

                      #11
                      Re: Non-virtual methods - why?

                      That's interesting - other examples?

                      "andrew queisser" <andrew.queisse r@hp.com> wrote in message
                      news:3f73198f$1 @usenet01.boi.h p.com...[color=blue]
                      > One common use is with the "Template Method" pattern:
                      > the base class declares a public non-virtual function which
                      > checks preconditions, calls a protected or private virtual
                      > function, then checks postconditions, like so:
                      >
                      > (F is non-virtual, DoF is protected virtual and probably abstract)
                      >
                      > int base::F(int i)
                      > {
                      > int ret;
                      > if (IsParamInRange (i))
                      > ret = DoF(i);
                      > if (IsRetInRange(r et))
                      > return ret;
                      > else
                      > return someError;
                      > }
                      >
                      > The idea is to force everyone to use a common "entry point"
                      > to some functionality with derived classes implementing specific
                      > tasks.
                      >
                      > Andrew
                      >
                      > "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
                      > news:%23yqf0Qug DHA.2352@TK2MSF TNGP09.phx.gbl. ..[color=green]
                      > > Hi all,
                      > >
                      > > In which circumstances it is appropriate to declare methods as[/color]
                      > non-virtual?[color=green]
                      > >
                      > > Thanx,
                      > > Adrian.
                      > >
                      > >[/color]
                      >
                      >[/color]


                      Comment

                      • Jon Skeet

                        #12
                        Re: Non-virtual methods - why?

                        Adrian Herscu <bmf1972@hotmai l.com> wrote:[color=blue][color=green]
                        > > Java *does* have non-virtual methods (they're called final in Java).
                        > > Look at Object.wait() for example.[/color]
                        >
                        > I think you are wrong. Read the Java Language Specification, para 8.4.3.3:
                        > "A method can be declared final to prevent subclasses from overriding or
                        > hiding it. It is a compile-time error to attempt to override or hide a final
                        > method".
                        >
                        > A final method in Java is close to a sealed method in C# - it prevents
                        > further overriding.[/color]

                        And that, as far as I'm concerned, is the principal feature of being
                        non-virtual.
                        [color=blue]
                        > In Java, methods can be hidden only by static methods - so, Java has no
                        > concept of non-virtual methods.[/color]

                        No, it has no concept of instance methods hiding other instance
                        methods, which I view as being separate from having no concept of non-
                        virtual methods.
                        [color=blue]
                        > While in C#, methods can be hidden because they were not marked virtual -
                        > so, in order to be sealed a method has to be virtual.[/color]

                        In my view, they can be sealed to prevent them being virtual any
                        further.

                        My way of looking at things is that something is virtual if it can be
                        overridden, and is non-virtual if it can't.

                        It's all a matter of definition, of course, but mine seems to fit in
                        pretty well with this section from the MSDN on virtual members:

                        <quote>
                        The virtual keyword is used to modify a method or property declaration,
                        in which case the method or the property is called a virtual member.
                        The implementation of a virtual member can be changed by an overriding
                        member in a derived class.

                        When a virtual method is invoked, the run-time type of the object is
                        checked for an overriding member. The overriding member in the most
                        derived class is called, which might be the original member, if no
                        derived class has overridden the member. (For more information on run-
                        time type and most derived implementation, see 10.5.3 Virtual methods.)

                        By default, methods are non-virtual. You cannot override a non-virtual
                        method.
                        </quote>

                        Here's another one, from the C# language specification:

                        <quote>
                        The implementation of a non-virtual method is invariant: The
                        implementation is the same whether the method is invoked on an instance
                        of the class in which it is declared or an instance of a derived class.
                        In contrast, the implementation of a virtual method can be superseded
                        by derived classes.
                        </quote>

                        A final method in Java absolutely satisfies the descriptions of non-
                        virtual methods above. Note that in neither of those two quotes is
                        hiding of methods mentioned.

                        --
                        Jon Skeet - <skeet@pobox.co m>
                        Pobox has been discontinued as a separate service, and all existing customers moved to the Fastmail platform.

                        If replying to the group, please do not mail me too

                        Comment

                        • Horatiu Ripa

                          #13
                          Re: Non-virtual methods - why?

                          I can't give you a good explanation of that. Especially because you can
                          "overwrite" a method even if it is not declared virtual in the base class
                          (by declaring a method with the same name an params in the child with "new")
                          and having the same behaviour. Probably the binding mechanisms take some
                          advantages of it, but it is just a supposition, I didn't explore this issue.
                          Another questions is "why not?". Anyhow I find it good as long as the code
                          is more readable and understandable, when you see the "override" keyword in
                          a method decalaration it is clear that it overrides/implements a method of a
                          base class.

                          Where?
                          1. In polymorphic structures, where the base class contains some common
                          behaviour/property that is the same for the derrived classes i.e.:
                          - shape (base) with circle, square, triangle (derrived): a setColor() method
                          is the same for all the shapes
                          2. In classes that contains general behaviours, when you want the derrived
                          classes only to extend the behaviours and not to change any of the base
                          behaviours i.e.:
                          - humanBeing (base) that contains goToSleep(), awake(), walk(), jump(),
                          stay(); women derrived from humanBeing that contains talkTooMuch(),
                          spendMensIncome () and man that contains watchAllSportAt TV(),
                          seekOtherWomen( ) and so on... :))

                          Anyhow you can do that explicitly by marking the methods as "sealed", and ,
                          as I already wrote, you can trick that.

                          --
                          Horatiu Ripa
                          Software Development Manager
                          Business Logic Systems LTD
                          21 Victor Babes str., 1st floor, 3400 Cluj-Napoca, Romania
                          Phone/Fax: +40 264 590703
                          Web: www.businesslogic.co.uk

                          This email (email message and any attachments) is strictly confidential,
                          possibly privileged and is intended solely for the person or organization to
                          whom it is addressed. If you are not the intended recipient, you must not
                          copy, distribute or take any action in reliance on it. If you have received
                          this email in error, please inform the sender immediately before deleting
                          it. Business Logic Systems Ltd accepts no responsibility for any advice,
                          opinion, conclusion or other information contained in this email or arising
                          from its disclosure.

                          "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
                          news:ewIpfn7gDH A.632@TK2MSFTNG P10.phx.gbl...[color=blue]
                          > That's interesting - other examples?
                          >
                          > "andrew queisser" <andrew.queisse r@hp.com> wrote in message
                          > news:3f73198f$1 @usenet01.boi.h p.com...[color=green]
                          > > One common use is with the "Template Method" pattern:
                          > > the base class declares a public non-virtual function which
                          > > checks preconditions, calls a protected or private virtual
                          > > function, then checks postconditions, like so:
                          > >
                          > > (F is non-virtual, DoF is protected virtual and probably abstract)
                          > >
                          > > int base::F(int i)
                          > > {
                          > > int ret;
                          > > if (IsParamInRange (i))
                          > > ret = DoF(i);
                          > > if (IsRetInRange(r et))
                          > > return ret;
                          > > else
                          > > return someError;
                          > > }
                          > >
                          > > The idea is to force everyone to use a common "entry point"
                          > > to some functionality with derived classes implementing specific
                          > > tasks.
                          > >
                          > > Andrew
                          > >
                          > > "Adrian Herscu" <bmf1972@hotmai l.com> wrote in message
                          > > news:%23yqf0Qug DHA.2352@TK2MSF TNGP09.phx.gbl. ..[color=darkred]
                          > > > Hi all,
                          > > >
                          > > > In which circumstances it is appropriate to declare methods as[/color]
                          > > non-virtual?[color=darkred]
                          > > >
                          > > > Thanx,
                          > > > Adrian.
                          > > >
                          > > >[/color]
                          > >
                          > >[/color]
                          >
                          >[/color]


                          Comment

                          • Adrian Herscu

                            #14
                            Re: Non-virtual methods - why?

                            "Jon Skeet" <skeet@pobox.co m> wrote in message
                            news:MPG.19dd8f d454ce10a798976 d@msnews.micros oft.com...[color=blue]
                            > Adrian Herscu <bmf1972@hotmai l.com> wrote:[color=green][color=darkred]
                            > > > Java *does* have non-virtual methods (they're called final in Java).
                            > > > Look at Object.wait() for example.[/color]
                            > >
                            > > I think you are wrong. Read the Java Language Specification, para[/color][/color]
                            8.4.3.3:[color=blue][color=green]
                            > > "A method can be declared final to prevent subclasses from overriding or
                            > > hiding it. It is a compile-time error to attempt to override or hide a[/color][/color]
                            final[color=blue][color=green]
                            > > method".
                            > >
                            > > A final method in Java is close to a sealed method in C# - it prevents
                            > > further overriding.[/color]
                            >
                            > And that, as far as I'm concerned, is the principal feature of being
                            > non-virtual.
                            >[/color]

                            No - the principal feature of being non-virtual, is that non-virtual methods
                            are resolved at compile-time (a.k.a. static or early binding), so a call
                            *always* executes the same implementation.
                            [color=blue]
                            >
                            >[color=green]
                            > > In Java, methods can be hidden only by static methods - so, Java has no
                            > > concept of non-virtual methods.[/color]
                            >
                            > No, it has no concept of instance methods hiding other instance
                            > methods, which I view as being separate from having no concept of non-
                            > virtual methods.
                            >[/color]

                            Think again. *Only* non-virtual methods can be "hidden".
                            [color=blue]
                            >[color=green]
                            > > While in C#, methods can be hidden because they were not marked[/color][/color]
                            virtual -[color=blue][color=green]
                            > > so, in order to be sealed a method has to be virtual.[/color]
                            >
                            > In my view, they can be sealed to prevent them being virtual any
                            > further.
                            >[/color]

                            "...virtual any further" = "...overrid en any further"
                            [color=blue]
                            >
                            > My way of looking at things is that something is virtual if it can be
                            > overridden, and is non-virtual if it can't.
                            >
                            > It's all a matter of definition, of course, but mine seems to fit in
                            > pretty well with this section from the MSDN on virtual members:
                            >
                            > <quote>
                            > The virtual keyword is used to modify a method or property declaration,
                            > in which case the method or the property is called a virtual member.
                            > The implementation of a virtual member can be changed by an overriding
                            > member in a derived class.
                            >
                            > When a virtual method is invoked, the run-time type of the object is
                            > checked for an overriding member. The overriding member in the most
                            > derived class is called, which might be the original member, if no
                            > derived class has overridden the member. (For more information on run-
                            > time type and most derived implementation, see 10.5.3 Virtual methods.)
                            >
                            > By default, methods are non-virtual. You cannot override a non-virtual
                            > method.
                            > </quote>
                            >[/color]

                            OK - but you can still hide it.
                            [color=blue]
                            >
                            > Here's another one, from the C# language specification:
                            >
                            > <quote>
                            > The implementation of a non-virtual method is invariant: The
                            > implementation is the same whether the method is invoked on an instance
                            > of the class in which it is declared or an instance of a derived class.
                            > In contrast, the implementation of a virtual method can be superseded
                            > by derived classes.
                            > </quote>
                            >
                            > A final method in Java absolutely satisfies the descriptions of non-
                            > virtual methods above. Note that in neither of those two quotes is
                            > hiding of methods mentioned.
                            >[/color]

                            A final method in Java absolutely does *not* satisfy the descriptions of
                            non-virtual methods above - simply because you cannot hide it as you can in
                            C#. Moreover, even a C# "sealed" method which is the most close to a Java
                            "final" method, can be hidden by further subclasses

                            There are two separate notions:
                            1) Overriding - by overriding, a subclass replaces method pointers in
                            object's v-table and since all method invokations are made through that
                            v-table, you will always get the overriding implementation no matter from
                            which site you call it (either from superclass' site or from subclass'
                            site) - hence, dynamic binding. Also, that's the reason for naming those
                            methods "virtual" - because their implementation is not known until
                            run-time.
                            2) Hidding - this is a totally different mechanism: method invokations are
                            resolved during compile-time (static binding); so, there is no v-table to go
                            through - the call is direct.

                            In summary: when you call a non-virtual method, you will _always_ get the
                            same implementation executed; when you call a virtual method, you will *not*
                            always get the same implementation executed - it depends on the overriding
                            subclasses.

                            //++ run this test ++++++

                            using System;

                            class A {
                            public void M1() {
                            Console.WriteLi ne("A::M1");
                            }

                            virtual public void M2() {
                            Console.WriteLi ne("A::M2");
                            }
                            }

                            class B : A {
                            new public void M1() {
                            Console.WriteLi ne("B::M1 - I'm hidding A::M1");
                            }

                            // only virtual methods can be sealed
                            sealed override public void M2() {
                            Console.WriteLi ne("B::M2 - I'm overriding A::M2");
                            }
                            }

                            class C : B {
                            new public void M1() {
                            Console.WriteLi ne("C::M1 - I'm hidding B::M1");
                            }

                            // still can hide (virtually!) the sealed base
                            new virtual public void M2() {
                            Console.WriteLi ne("C::M2 - I'm hidding B::M2, since it is sealed");
                            }
                            }

                            class TestDerivation {
                            static void Main() {
                            A objA;

                            objA = new A();
                            objA.M1();
                            objA.M2();

                            objA = new B();
                            objA.M1(); // non-virtual - A::M1 implementation will execute
                            objA.M2(); // virtual - B::M2 implementation will execute

                            objA = new C();
                            objA.M1(); // non-virtual - A::M1 implementation will execute
                            objA.M2(); // virtual and sealed at B class level
                            // - B::M2 implementation will execute
                            }
                            }
                            [color=blue]
                            > --
                            > Jon Skeet - <skeet@pobox.co m>
                            > http://www.pobox.com/~skeet
                            > If replying to the group, please do not mail me too[/color]




                            Comment

                            • 100

                              #15
                              Re: Non-virtual methods - why?

                              Hi,
                              [color=blue][color=green][color=darkred]
                              > > > Java *does* have non-virtual methods (they're called final in Java).
                              > > > Look at Object.wait() for example.[/color]
                              > >
                              > > I think you are wrong. Read the Java Language Specification, para[/color][/color]
                              8.4.3.3:[color=blue][color=green]
                              > > "A method can be declared final to prevent subclasses from overriding or
                              > > hiding it. It is a compile-time error to attempt to override or hide a[/color][/color]
                              final[color=blue][color=green]
                              > > method".
                              > >
                              > > A final method in Java is close to a sealed method in C# - it prevents
                              > > further overriding.[/color]
                              >
                              > And that, as far as I'm concerned, is the principal feature of being
                              > non-virtual.[/color]
                              I don't know how is in JAVA, but if you assert here that declaring a method
                              as *sealed* si the same as declaring non-virtual method you are wrong. Such
                              a method is still virtulal.

                              class A
                              {
                              public virtual void f()
                              {
                              }
                              }

                              class B: A
                              {
                              public override void f()
                              {
                              }
                              }

                              class C: B
                              {
                              public override sealed void f();
                              {
                              }
                              }

                              A a = new C()
                              a.f() calls C.f()
                              Isn't it virtual? If it wasn't it would call A.f()
                              *sealed* modifier force you to stop using overriden until you don't use
                              *virtual* again and then you can continue override the method. BTW the
                              compiler generates *callvirt* instruction as a evidence of that the method
                              is indeed *virtual*

                              [color=blue][color=green]
                              > > While in C#, methods can be hidden because they were not marked[/color][/color]
                              virtual -[color=blue][color=green]
                              > > so, in order to be sealed a method has to be virtual.[/color]
                              >
                              > In my view, they can be sealed to prevent them being virtual any
                              > further.[/color]

                              In c# you can keep going with overrideing the method which was sealed. what
                              you have to is to declared it as virtual again(to start new virtual
                              implemetation).

                              That is posible because when CLR decides, which is most-derived method it
                              doesn't take into account only the runtime type of the object it kind of
                              takes into account the type of the variable as well.
                              To be more strict
                              callvirt is provided with the name of the class from where to start looking
                              for the most-derived implementation.[color=blue]
                              >
                              > My way of looking at things is that something is virtual if it can be
                              > overridden, and is non-virtual if it can't.[/color]

                              When you put *sealed* modifier for a method you have to put override as well
                              (other wise it does'n make sence to prohibit overriding of something which
                              cannot be overrided anyway). The modifier *override* already means that the
                              method is virtual.
                              [color=blue]
                              > It's all a matter of definition, of course, but mine seems to fit in
                              > pretty well with this section from the MSDN on virtual members:
                              >
                              > <quote>
                              > The virtual keyword is used to modify a method or property declaration,
                              > in which case the method or the property is called a virtual member.
                              > The implementation of a virtual member can be changed by an overriding
                              > member in a derived class.
                              >
                              > When a virtual method is invoked, the run-time type of the object is
                              > checked for an overriding member. The overriding member in the most
                              > derived class is called, which might be the original member, if no
                              > derived class has overridden the member. (For more information on run-
                              > time type and most derived implementation, see 10.5.3 Virtual methods.)
                              >
                              > By default, methods are non-virtual. You cannot override a non-virtual
                              > method.
                              > </quote>[/color]

                              If you read further down the same section you will find example of hiding
                              virtual methods, which is more closely to what happend when you declare a
                              method as a *sealed*. *sealed* modifier just force you to hide the method if
                              you want to change the implementation.


                              [color=blue]
                              > Here's another one, from the C# language specification:
                              >
                              > <quote>
                              > The implementation of a non-virtual method is invariant: The
                              > implementation is the same whether the method is invoked on an instance
                              > of the class in which it is declared or an instance of a derived class.
                              > In contrast, the implementation of a virtual method can be superseded
                              > by derived classes.
                              > </quote>
                              >
                              > A final method in Java absolutely satisfies the descriptions of non-
                              > virtual methods above. Note that in neither of those two quotes is
                              > hiding of methods mentioned.[/color]

                              If *final* in JAVA means that the method cannod be overriden or hid then it
                              is different form the non-virtual methods.
                              Non-virtual methods cannot be overriden - OK. One can hide then, though.

                              So my question is: Why C# allows virtual methods to be hidden. Isn't it
                              error prone.
                              I believe that the best is:
                              1. To have virtual and non-virtual methods.
                              2. Sealing virtual methods has to prevent further overriding and hiding the
                              methods.

                              And actually I think I know the answer. It is side efect of the way the CLR
                              resolves wich is the most-derived method. .NET is cross langage platform and
                              if C# was preventing this using calsses written in other languges (allowing
                              hiding virtual methods) would put C# programmers to consfusion.

                              B\rgds
                              100


                              Comment

                              Working...