Re: Do we need Overidable?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 11 of 11

Thread: Re: Do we need Overidable?

  1. #1
    Bill McCarthy Guest

    Re: Do we need Overidable?

    Hi Jeff,

    this one must have slipped under the radar, sorry. I just noticed it when I
    was looking to see whether or not Jonathan had admitted to his mistake <g>

    "Jeff Peil" <jpeil@bigfoot.com> wrote in message
    news:3a6bc9b3$1@news.devx.com...
    >
    > I understood that there wasn't a conflict at the getter/setter level, I
    > merely inferred (perhaps incorrectly) that you were suggesting doing this

    so
    > that the getter could be used through references to the type from outside
    > the assembly, and the setter could be accessed within the assembly (getter
    > could be accessed still internally through a cast, of course.)
    >


    I wouldn't recommend it mind you, but that was what that code basically did,
    yes. I don't like that code one bit as it really is unclear exactly what it
    does unless you have the code for both classes or at least know that the
    base class is readonly etc. Viewing it in the object browser or ILDASM
    definetly does not make it clear <bg> IMO, the masking should have to be
    explicitly for getter and/or setter, not property. And of course, if we go
    down that track then we can have, or should be able to have mixed access for
    getter setter without the new or shadows keyword, but that's another story



    > Personally I consider C#'s choice here to be rather poor. IMO, the
    > visibility of a member should not impact it's name hiding affect as

    someone
    > looking at the members in the derived type may see a
    > private/protected/internal member that does what he/she wants and tries
    > calling it, without error, only to find out later that the call was
    > compiling implicitly to a different function entirely.


    Yep, I can see advantages in what I think you are saying, as if I shadow a
    public method with an internal method, then for an external caller on the
    object that method would be totally hidden.

    > As the hidden member
    > will always be available through a cast to the declaring base, imo, a

    member
    > declared in a derived type that masks a member of a base type should cause
    > the base type's member to be masked through a reference to the derived

    type
    > regardless of the visibility of the derived member.
    >


    Uhm, no ?? I think that is what overrides is really for. For the visibility
    thing, I would prefer overrides not to have to have the same visibility as
    the member it is overriding, rather than using shadows.










  2. #2
    Jeff Peil Guest

    Re: Do we need Overidable?


    "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    news:3a6fb990@news.devx.com...
    >
    > > As the hidden member
    > > will always be available through a cast to the declaring base, imo, a

    > member
    > > declared in a derived type that masks a member of a base type should

    cause
    > > the base type's member to be masked through a reference to the derived

    > type
    > > regardless of the visibility of the derived member.
    > >

    >
    > Uhm, no ?? I think that is what overrides is really for. For the

    visibility
    > thing, I would prefer overrides not to have to have the same visibility as
    > the member it is overriding, rather than using shadows.
    >

    Perhaps you misunderstood me, as it wasn't exactly the clearest sentence
    I've ever tossed together =)

    All I was saying is that if you hide a member through shadowing, an upcast
    to the base type (where the member is visible) will allow you to access it.
    As the member is still accessible through a cast, it is better in my opinion
    for the member to be hidden from any context where a reference to the
    derived type is used, and not only from contexts where the derived member is
    accessible. For example, an internal method that shadows a base method
    should shadow it in all contexts (and not just inside the assembly where the
    internal method is accessible.)



  3. #3
    Mark Burns Guest

    Re: Do we need Overidable?


    "Jeff Peil" <jpeil@bigfoot.com> wrote in message
    news:3a6fcb91@news.devx.com...
    >
    > "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    > news:3a6fb990@news.devx.com...
    > >
    > > > As the hidden member
    > > > will always be available through a cast to the declaring base, imo, a

    > > member
    > > > declared in a derived type that masks a member of a base type should

    > cause
    > > > the base type's member to be masked through a reference to the derived

    > > type
    > > > regardless of the visibility of the derived member.
    > > >

    > >
    > > Uhm, no ?? I think that is what overrides is really for. For the

    > visibility
    > > thing, I would prefer overrides not to have to have the same visibility

    as
    > > the member it is overriding, rather than using shadows.
    > >

    > Perhaps you misunderstood me, as it wasn't exactly the clearest sentence
    > I've ever tossed together =)
    >
    > All I was saying is that if you hide a member through shadowing, an upcast
    > to the base type (where the member is visible) will allow you to access

    it.
    > As the member is still accessible through a cast, it is better in my

    opinion
    > for the member to be hidden from any context where a reference to the
    > derived type is used, and not only from contexts where the derived member

    is
    > accessible. For example, an internal method that shadows a base method
    > should shadow it in all contexts (and not just inside the assembly where

    the
    > internal method is accessible.)
    >


    Ok, I've been lurking here up 'till now. ...but now I have a question (as
    I'm attempting to understand all this).
    Given initial conditions (gross pseudocode follows):

    Class ABase
    property Thingy()
    get
    set
    end property
    end class

    class AInheritor
    inherits ABase
    property Anotherthingy(i as integer)
    get
    set
    end property
    end class

    ....now things are pretty clear.
    ...but now, the ABase class is modified adding:

    Property AnotherThingy(str as string, obj as object)
    get
    set
    end property

    ....and AInheritor must now be modified by making its Anotherthingy property
    shadowed...right?

    Now, in new client code which instantiates the AInheritor class, how
    can/does one tell which AnotherThingy property will be called, the shadowed
    implementation or the base implementation? (in this case, especially since
    the property signiatures are, deliberately, so different...could/should
    overloading be used here? ...and how?)




  4. #4
    Jeff Peil Guest

    Re: Do we need Overidable?

    Hi Mark,

    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a705cbc@news.devx.com...
    >
    > Ok, I've been lurking here up 'till now. ...but now I have a question (as
    > I'm attempting to understand all this).
    > Given initial conditions (gross pseudocode follows):


    Just so we're clear when I say "should" I don't mean "will" rather my design
    philosphy here clearly differs from the people who designed C#. C# takes a
    different approach, that does have arguable merits, just ones I happen to
    disagree with. More comments follow.

    > Class ABase
    > property Thingy()
    > get
    > set
    > end property
    > end class
    >
    > class AInheritor
    > inherits ABase
    > property Anotherthingy(i as integer)
    > get
    > set
    > end property
    > end class
    >
    > ...now things are pretty clear.


    Right, so far everyone is happy. The thing to remember is that ABase may be
    a class supplied by a vendor that you have no control over (which is why
    such a thing is likely, as it would generally not be something you would
    want to intentionally introduce into a codebase you controlled yourself.)

    > ..but now, the ABase class is modified adding:
    >
    > Property AnotherThingy(str as string, obj as object)
    > get
    > set
    > end property


    Well right here you haven't introduced a problem for C# or VB as these two
    indexed properties use different criteria for indexing (one indexes on
    "integer" the other on "string, object") If the two were to collide you'd
    have an issue. So instead lets say that ABase is modified adding

    Property AnotherThingy(i as integer) as object
    get
    set
    end property

    > ...and AInheritor must now be modified by making its Anotherthingy

    property
    > shadowed...right?


    Yes and no. When AInheritor is recompiled it will probably be necessary (I
    say probably because in VB.NET the behavior isn't there in Beta1, and the
    VB.NET designers could either decide to issue an error and stop compiling,
    or they could just issue a warning and implicitly compile it as a shadows.)
    Until you have to recompile AInheritor the property will automatically act
    as a shadows of the property in ABase.

    > Now, in new client code which instantiates the AInheritor class, how
    > can/does one tell which AnotherThingy property will be called, the

    shadowed
    > implementation or the base implementation? (in this case, especially since
    > the property signiatures are, deliberately, so different...could/should
    > overloading be used here? ...and how?)


    Through a reference to ABase (that is if you have a ABase reference, and it
    points at *either* an ABase or an AInheritor object) you will get the
    property defined in ABase.

    Through a reference to AInheritor (or a type further derived from AInheritor
    that doesn't further shadow the property) you will get the property defined
    in AInheritor (regardless of when this code was compiled)

    If this is still unclear, just ask and I can probably put together a clear
    example for you.

    Anyways, hope that helps



  5. #5
    Bill McCarthy Guest

    Re: Do we need Overidable?

    Hi Jeff,

    "Jeff Peil" <jpeil@bigfoot.com> wrote in message
    news:3a6fcb91@news.devx.com...
    >
    > Perhaps you misunderstood me, as it wasn't exactly the clearest sentence
    > I've ever tossed together =)
    >


    Gotta admit, I was scratching the ol' noggin a few times try to work out
    exactly what you meant <g>, but it does look like I read you right the first
    time. Dunno how we got the wires crossed though <g>

    >
    > For example, an internal method that shadows a base method
    > should shadow it in all contexts (and not just inside the assembly where

    the
    > internal method is accessible.)
    >


    Yeh, but that would mean you could declare a Shadow as Friend (or internal
    <yuk>), and for external ref to the object the public method would also
    always be hidden. I think I said I can see advantages in that, but Shadows
    is meant, as is implemented as such, to be a scoping tool of sorts. Waht you
    are saying would in fact be overriding, not scoping.

    Anyway, on a tangent (yes ,another one<g>), what do you think above
    pros/cons of having Overrides being able to declare different accessibility,
    eg: an Override being able to be declared as Friend when the base method is
    Public, ??










  6. #6
    Mark Burns Guest

    Re: Do we need Overidable?


    "Jeff Peil" <jpeil@bigfoot.com> wrote in message
    news:3a7147f5@news.devx.com...
    > Hi Mark,
    >
    > > ..but now, the ABase class is modified adding:
    > >
    > > Property AnotherThingy(str as string, obj as object)
    > > get
    > > set
    > > end property

    >
    > Well right here you haven't introduced a problem for C# or VB as these two
    > indexed properties use different criteria for indexing (one indexes on
    > "integer" the other on "string, object") If the two were to collide you'd
    > have an issue. So instead lets say that ABase is modified adding
    >
    > Property AnotherThingy(i as integer) as object
    > get
    > set
    > end property


    Uhm. Ok...what am I failing to understand here...the compiler will, in my
    original instance do the equivilant of an "automagic overload" of the two
    AnotherThingy(int)/(string,object) methods?...if that's right, then for both
    VB.net and C#?

    > > ...and AInheritor must now be modified by making its Anotherthingy

    > property
    > > shadowed...right?

    >
    > Yes and no. When AInheritor is recompiled it will probably be necessary

    (I
    > say probably because in VB.NET the behavior isn't there in Beta1, and the
    > VB.NET designers could either decide to issue an error and stop compiling,
    > or they could just issue a warning and implicitly compile it as a

    shadows.)
    > Until you have to recompile AInheritor the property will automatically act
    > as a shadows of the property in ABase.
    >
    > > Now, in new client code which instantiates the AInheritor class, how
    > > can/does one tell which AnotherThingy property will be called, the

    > shadowed
    > > implementation or the base implementation? (in this case, especially

    since
    > > the property signiatures are, deliberately, so different...could/should
    > > overloading be used here? ...and how?)

    >
    > Through a reference to ABase (that is if you have a ABase reference, and

    it
    > points at *either* an ABase or an AInheritor object) you will get the
    > property defined in ABase.
    >
    > Through a reference to AInheritor (or a type further derived from

    AInheritor
    > that doesn't further shadow the property) you will get the property

    defined
    > in AInheritor (regardless of when this code was compiled)


    Ok, I think I got that. Thanks a ton.

    > If this is still unclear, just ask and I can probably put together a clear
    > example for you.


    Well... an example is always nice...just to make sure.




  7. #7
    Jeff Peil Guest

    Re: Do we need Overidable?


    "Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
    news:3a717905@news.devx.com...
    > Yeh, but that would mean you could declare a Shadow as Friend (or internal
    > <yuk>), and for external ref to the object the public method would also
    > always be hidden. I think I said I can see advantages in that, but

    Shadows
    > is meant, as is implemented as such, to be a scoping tool of sorts. Waht

    you
    > are saying would in fact be overriding, not scoping.


    No.

    Overriding (in the VB keyword sense) involves changing *polymorphic*
    behavior. Shadowing involves changing static behavior. When accessing a
    member through a reference to the base class, if you have an overrides
    involved, should the reference be to an overriding derived type then the
    derived method will be called. Shadowing should not impact polymorphic
    behavior (outside late bound situations.)

    Yes I do mean that a shadow as friend (or internal) SHOULD hide the public
    method declared in the base type from all contexts (outside an explicit
    upcast to the base where the public method/property would be visible for
    usage with an instance of the derived type.) The reason for this is simple.
    People are likely to read the documentation for a class by looking at the
    most derived type that they are working with, and see documentation for
    properties/methods there. When they see a method/property described with
    one set of behavior and overlook the accessibility, then try to use that
    property from a context where it would be illegal, if the method/property is
    not shadowing a more visible method/property in a base class they will
    clearly get a compile time error. If the method/property hapens to have
    shadowed a visible method in a base class, you suddenly have a much worse
    scenario, the code compiles and merely does not behave as expected.

    I believe it is preferable to have the added work of explicitly using a
    reference to the base class pointing at an instance of the derived class
    when you need to call the shadowed method/property defined in the base class
    as the added benefit is better compile-time protection.

    > Anyway, on a tangent (yes ,another one<g>), what do you think above
    > pros/cons of having Overrides being able to declare different

    accessibility,
    > eg: an Override being able to be declared as Friend when the base method

    is
    > Public, ??


    Personally I don't have a problem with increasing visibility, however
    allowing someone to decrease visibility for an override makes little sense.
    The method is still going to be accessible at it's greatest level of
    visibility because the override is still callable by casting up to the base
    class and then calling it. Of course I also don't see much benefit in
    allowing the visibility to be changed in any event, so I can agree with
    keeping the language simpler and completely disallowing it.



  8. #8
    Jeff Peil Guest

    Re: Do we need Overidable?


    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a71a75a@news.devx.com...
    > Uhm. Ok...what am I failing to understand here...the compiler will, in my
    > original instance do the equivilant of an "automagic overload" of the two
    > AnotherThingy(int)/(string,object) methods?...if that's right, then for

    both
    > VB.net and C#?


    For C# yes (C# doesn't require any explicit syntax to specify a
    method/indexer is overloading another method/indexer.)

    For VB.NET when you recompile ABase, yes until AInheritor is recompiled the
    property there will act as an overload automatically. When it comes time to
    recompile AInheritor, the compiler would complain that the property in
    AInheritor overloads the property in ABase and needs to be declared as an
    overloads (so to recompile AInheritor *after* ABase had the property was
    added, you would need to add the overloads keyword, but until you recompiled
    the property in AInheritor would act as if it had been declared as an
    overload.)





  9. #9
    Mark Burns Guest

    Re: Do we need Overidable?


    "Jeff Peil" <jpeil@bigfoot.com> wrote in message
    news:3a71d85e@news.devx.com...
    >
    > "Mark Burns" <mark@iolofpa.com> wrote in message
    > news:3a71a75a@news.devx.com...
    > > Uhm. Ok...what am I failing to understand here...the compiler will, in

    my
    > > original instance do the equivilant of an "automagic overload" of the

    two
    > > AnotherThingy(int)/(string,object) methods?...if that's right, then for

    > both
    > > VB.net and C#?

    >
    > For C# yes (C# doesn't require any explicit syntax to specify a
    > method/indexer is overloading another method/indexer.)
    >
    > For VB.NET when you recompile ABase, yes until AInheritor is recompiled

    the
    > property there will act as an overload automatically. When it comes time

    to
    > recompile AInheritor, the compiler would complain that the property in
    > AInheritor overloads the property in ABase and needs to be declared as an
    > overloads (so to recompile AInheritor *after* ABase had the property was
    > added, you would need to add the overloads keyword, but until you

    recompiled
    > the property in AInheritor would act as if it had been declared as an
    > overload.)


    ....and is-this/how-is-this picture complicated if the new, identically-named
    property/method in ABase is not marked as overridable (by AInheritor)? Is
    this the scenario where shadows comes in and what you said in your first
    reply holds true - even if the two property/methods signiatures are
    different? ...or am I totally missing something still?






  10. #10
    Jeff Peil Guest

    Re: Do we need Overidable?


    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a7241f3@news.devx.com...
    >
    > ...and is-this/how-is-this picture complicated if the new,

    identically-named
    > property/method in ABase is not marked as overridable (by AInheritor)? Is
    > this the scenario where shadows comes in and what you said in your first
    > reply holds true - even if the two property/methods signiatures are
    > different? ...or am I totally missing something still?
    >


    When ABase is modified, and the property is added, it does not matter if the
    property in ABase is overridable or not. The property in AInheritor at this
    point will act as a shadows (nor does AInheritor's property being
    overridable make any difference at this point.)

    When you recompile AInheritor, the error/warning that you get will probably
    be different depending on the overridable status of both ABase's and
    AInheritor's properties but the effect will be the same. If you want things
    to keep acting the way they were acting prior to recompiling AInheritor, you
    simply would add the shadows modifier.

    Of course, in practice, when a base class is modified to expose a property
    or method with the same name as a property or method in a derived class, you
    would probably want to seriously consider changing the name used in the
    derived type that you control In some cases leaving the method/property
    shadowed is better than breaking the derived type's contract and renaming or
    merging the method/property declared in the deriving type that conflicts
    with the new member added to the base type. When breaking the derived
    type's contract will have a minimal impact, changing the derived type so
    that it does not rely on shadowing will lead to more maintainence friendly
    code (so when a relativly a small amount of code relies on the effected
    part of the derived type's contract, and you can easily modify that code as
    necessary, the refactoring is probably the better long term approach.)



  11. #11
    Mark Burns Guest

    Re: Do we need Overidable?


    "Jeff Peil" <jpeil@bigfoot.com> wrote in message
    news:3a7251a6@news.devx.com...
    >


    Ok, got it. Thanks much! :-)



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center