Re: C# Override limitation..why?
- From: "Daniel O'Connell [C# MVP]" <onyxkirx@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 9 Jun 2005 15:17:47 -0500
<Cliff_Harker@xxxxxxxxxxx> wrote in message
news:1118243028.016782.131450@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> I'm not really suggesting the compiler/runtime does anything any
> different than it does now.
>
> OK, in your example you end up with
>
> a.whatever(new A()) calling b.whatever(A) but whats the problem it can
> still call a.whatever(A) though the normal virtual lookup tables (or
> whatever it uses). It knows B is based on A and it knows its an
> override so why can't it look for base.whatever(a) in the base class?
>
> Why can't the compiler say
>
> "OK it should be an A, but it's a B, but that's OK because B is based
> on A" and just carry on creating the same code it does now as if I had
> declared in identically.
>
> I suppose all I'm saying is that when it finds "override" it should
> look for methods in the base class where the signature parameters match
> at "some base class level" and allow it. It then generates code as it
> would have done had they been identical.
>
> Perhaps I'm missing some fundamental point but it feels sensible that a
> base method accepting a base class could be overridden by a superset
> class and method, after all it contains an instance of the base class.
>
Consider this, in your B class method you write
override int Method(B b)
{
b.SomeMethodThatIsNotInA();
}
How can you generate identical code for that? It's not that the compiler
can't treat a derived type as its base type, its that by doing so you defeat
the purpose of this feature to begin with. What good does it do, outside of
very strict type safety, to require type B in a spot where only type A's
interface can be used?
Best as I can tell, from all of the posts here, is that you want to make the
compiler *pretend* to override something but actually to generate method
overloads and then do dynamic dispatch based on actual type instead of
static dispatch based on expression type. To me, that is downright silly and
a waste of time(not to mention wholly different from the rest of the
langauge). If you want to dispatch to a method based on exact instance type,
write a reflection based dispatcher and be done with it(it'll take you 20
minutes, tops). If you want to provide overloads, do so, but don't expect
the compiler to do all the work for you.
What you seem to want doesn't make sense as a language feature directly and
can very easily be provided by a class.
What you are looking at here is called "covariant" arguments, and it has the
issues mentioned here(I don't know a language that supports it off hand, but
its not generally accepted, its exclusion was not simply arbitrary).
Contravariant arguments, something like:
virtual void Method(string x)
{
}
override void Method(object x)
{
}
are more commonly used and would work fine in C# as long as you don't make a
base call, but are not currently supported. Covariance does work for return
types, however:
virtual A Method()
{
}
override B Method()
{
}
although it is not currently supported either. Dig around and see what you
can find on covariant arugments, see if you think they are still a good idea
and if you can find an argument to really support them.
.
- References:
- C# Override limitation..why?
- From: Cliff_Harker
- Re: C# Override limitation..why?
- From: Christof Nordiek
- Re: C# Override limitation..why?
- From: Cliff_Harker
- C# Override limitation..why?
- Prev by Date: Getting SelectedText/Item from ComboBox
- Next by Date: Re: How to do type conversion to unknown type?
- Previous by thread: Re: C# Override limitation..why?
- Next by thread: RE: C# Override limitation..why?
- Index(es):
Relevant Pages
|
Loading
