Re: Do we need Overidable?

[Bill McCarthy]

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.

[Jeff Peil]

"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.)

[Mark Burns]

"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?)

[Jeff Peil]

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

[Bill McCarthy]

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, ??

[Mark Burns]

"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.

[Jeff Peil]

"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.

[Jeff Peil]

"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.)

[Mark Burns]

"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?

[Jeff Peil]

"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.)

[Mark Burns]

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

Ok, got it. Thanks much! :-)