Skip to content
This repository has been archived by the owner on Aug 24, 2022. It is now read-only.

Implement full IL .overrides and virtual semantics #185

Open
kg opened this issue Apr 24, 2013 · 7 comments · May be fixed by #993
Open

Implement full IL .overrides and virtual semantics #185

kg opened this issue Apr 24, 2013 · 7 comments · May be fixed by #993

Comments

@kg
Copy link
Member

kg commented Apr 24, 2013

The way .overrides and virtual work in IL, you can actually have multiple chains of virtual methods with the same name on an object, by using 'new' to establish a new chain. It's also possible to use .overrides to override ordinary virtual methods instead of just interface methods.

C# and VB.net don't use either of these features extensively (though it's possible to do the chains using a mixture of 'new' and 'virtual') but it is probably necessary to implement this at some point anyway.

@iskiselev
Copy link
Member

Probably it's time to discuss ways for implementing this.

@iskiselev
Copy link
Member

As I understand, this is covered by FailingTests\InheritedAndNewMethod.cs and FailingTests\VirtualAndNewMethods.cs. FailingTests\BaseFields.cs is also related to same problem.

@kg
Copy link
Member Author

kg commented Nov 19, 2015

I don't understand this aspect of the CLR especially well, I should probably find time to read over the relevant parts of the spec and figure out how we'd make this work.

@iskiselev
Copy link
Member

Probably when we will implement it, we should also think about members with compilercontrolled visibility.
Such members could have same name and signature. ILDASM works with tham by adding '$PST' + some unique identifier, and ilasm strip his identifier. Have not yet tested what JSIL will do with them (icsharpcode/ILSpy#186 - looks like they are supported by ILSpy), but even if we call them correctly due to '$PST' suffix, we still need handle this as special case in reflection.

@iskiselev
Copy link
Member

We may use VirtualMethod (same as we use InterfaceMethod now) to select which class virtual method should be selected. The main problem with this aproach - class could have static method with same name as virual instance method, so we can't just attach VirtualMethods to class public interface (as we do with InterfaceMethods). We still could add $VitualMethods property to class public interface and attach it to them.

@iskiselev
Copy link
Member

Really, we actually may need always use class-aware method specification, otherwise we we'll be unable select correct method in cases like #623.

@iskiselev
Copy link
Member

Really, this and 623 are totally same problem - we can have same-named method that associated with different type in inheritance hierarchy, so we need specify in call which type method would we like to call.
So, same as with interface member, we should pass to signature as first aument pair of type and name.

@iskiselev iskiselev linked a pull request Jun 9, 2016 that will close this issue
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants