Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / September 2005

Tip: Looking for answers? Try searching our database.

Overriding generic methods

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
George - 20 Sep 2005 12:46 GMT
Hi,

Extras from ECMA standard, 3rd edition:

"If an overridden generic method has one or more constraints on its generic
arguments then:
• ...
• Any such constraint on a generic argument specified by the overriding
method shall be no more restrictive than the constraint specified by the
overridden method for the same generic argument;"

It's not quite clear to me what means "no more restrictive".

I thought that it's about the subtyping relation. This would mean that,
assuming B is a subclass of A, it's alright if "void m<(A) X>()" overrides
"void m<(B) X>()" as A is not more restrictive than B ...  However, such an
example is rejected by the verifier.

After looking at the C#2.0 Spec, I think that, relative to a given generic
parameter, the verifier checks that either the overriding method has no
constraint or has the "same" constraint. This would explain why the above
example is rejected.

Thank you.
George
Oliver Sturm - 21 Sep 2005 10:29 GMT
>Extras from ECMA standard, 3rd edition:
>
[quoted text clipped - 16 lines]
>constraint or has the "same" constraint. This would explain why the above
>example is rejected.

Well, I assumed that this is about constraints on base class methods, like
here:

  class A {
    public virtual void Foo<T>() where T: ISomething {
    }
  }

  class B : A {
    public override void Foo<T>() {
    }
  }

This code compiles. What I thought the paragraph was about was that when I
decided to add constraints to the overridden method in B as well, that
these constraints couldn't be more restrictive than those on the
overridden method. But when I tried to test this by changing the method
signature of B.Foo to this:

  public override void Foo<T> where T: ISomething, new()

I found that this isn't allowed at all - the compiler just says
"Constraints for override and explicit interface implementation methods
are inherited from the base method so cannot be specified directly." So
now I have to admit I really have no idea from the top of my head what
this paragraph is talking about.

               Oliver Sturm
Signature

Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

George - 21 Sep 2005 19:44 GMT
Thanks Oliver for the answer.

>    class A {
>      public virtual void Foo<T>() where T: ISomething {
[quoted text clipped - 7 lines]
>
> This code compiles.

yes, because the constraint is inherited. This can be seen also in the
bytecode where
B::Foo looks B::Foo<(ISomething) T>()

> that
> these constraints couldn't be more restrictive than those on the
> overridden method. But when I tried to test this by changing the method
> signature of B.Foo to this:
>
>    public override void Foo<T> where T: ISomething, new()

but you're more restrictive here by adding "new()". anyway, even if you are
not more restrictive, the verifier rejects.

> I really have no idea from the top of my head what
> this paragraph is talking about.

I really think that this "no more restrictive than" has to do with the
subtyping relation, BUT it's not currently implemented like that in the
verifier (Version  2.0.50215.44).

George
Oliver Sturm - 21 Sep 2005 19:54 GMT
>>    public override void Foo<T> where T: ISomething, new()
>
[quoted text clipped - 7 lines]
>subtyping relation, BUT it's not currently implemented like that in the
>verifier (Version  2.0.50215.44).

What I really wanted to say with my post is that nothing seems to be
rejected on the basis of being more or less restrictive in a derived class
- the message says that putting constraints on overridden methods in
derived classes is outright forbidden. That's why I said I don't
understand  the paragraph because it really seems to specify something
completely useless.

               Oliver Sturm
Signature

Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

George - 21 Sep 2005 21:37 GMT
> That's why I said I don't
> understand  the paragraph because it really seems to specify something
> completely useless.

Oliver, you were referring to C# while I was actually pointing to CIL
bytecode.

In the bytecode, you are allowed to write the same constraint in the
overriding method or to write none (which is the same as writing object). At
least, this is allowed by the current verifier ... although ECMA states that
it shall allow more.

George

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.