Roslyn: base keyword not detect extension method

[Thaina]

Basically

this keyword work fine without error. So base should not be differenced

[HaloFour]

Why would it be necessary to use extension methods with base? It's not like you could treat the target any differently than this. If anything that would probably lead to confusion as you might expect that the extension method could call virtual members of the base type directly rather than invoking the overridden member on the derived type. You probably shouldn't be using base in any scenario other than where you intend to bypass virtual method dispatch or invoke a parent constructor.

[Thaina]

@HaloFour In this case I intend to have extension method call virtual method of base class, get the type of base class, do the reflection and view the member of the base class. And so on in the extension method

[HaloFour]

@Thaina

What you described wouldn't be possible anyway. The base keyword doesn't change the type of the instance at all. If the extension method called obj.GetType() it would still return typeof(Test). If you attempted to invoke a virtual method it would still end up calling the overridden method. There's nothing in the C# language (or the CLR for that matter) which supports that behavior and allowing for base to resolve extension methods wouldn't change that.

[Thaina]

@HaloFour What I write is something like this

```C#
public static class Ext
{
public static void DoSomething(this T obj) where T : B
{
bool hasISomething = typeof(ISomething).IsAssignableFrom(typeof(T));
obj.Do();
}
}

public class B
{
public virtual void Do(){}
}

public class A : B,ISomething
{
public override void Do(){}
void Work()
{
base.DoSomething();
}
}
```

This is not exactly I was written. just make a quick example that sometimes I want to use base as the extension method so the type T will be the type of base and virtual method will call the base one

[HaloFour]

just make a quick example that sometimes I want to use base as the extension method so the type T will be the type of base

For as rare as such a use case would be you could always just call the extension method and supply the generic type argument:

this.DoSomething<B>();

and virtual method will call the base one

Even if the above example would compile and the T generic type parameter resolved correctly to B the call to obj.Do() would still call A.Do, not B.Do, because obj is a A and it's vtable entry for Do points to A.Do. The only way to call B.Do is from within A using base.Do() directly.

Note that you cannot use base for anything except calling a parent constructor or calling a parent member. You cannot take a reference to it. You cannot pass it to any methods. This is because base as a keyword isn't an expression and doesn't resolve in a value. It's not possible to get a reference to base which acts like a B.

[eyalsk]

@Thaina Just out of curiosity why the method DoSomething is generic? you return void so it seems like doing something like DoSomething(this B obj) should be sufficient, isn't? _I might be missing something but thought to point this out. :)_

[Thaina]

@eyalsk In this case I write it as generic so whenever I try to call that method. I always know the type it supplied at call site even the object itself is null

But normally I also like to write extension method like that. Because I would constraint it as interface and it could pass struct without boxing

[Thaina]

@HaloFour I was written it like that now but it just not satisfied because normally I could let it do type inference without supplying generic

[jnm2]

Heh, this reminds me of my LanguageUtils.ExplicitImplementation<BaseClass, IInterface>(this).InterfaceMember(...) which saved the day with a poor 3rd party library API where I needed to override a class's explicit interface implementation but conditionally call the base implementation.

I still have an open ticket with them to provide protected virtual methods. -_-

[Thaina]

Your reminder also remind me when I want to call function in base class of the base class. base.base.DoSomething() could not work

[eyalsk]

I've deleted my posts because while my _idea_ is pretty much what the spec says, you can't really do ((MyBase)this) or (MyBase1)((MyBase2)this), well you can but it's redundant, it doesn't really points to the base or the base of the base class, this always points to the derived class.

However, what you're asking with base.base.DoSomething() is that at binding time this will happen (MyBase1)((MyBase2)this).DoSomething()

Citing the spec:

At binding-time, base_access expressions of the form base.I and base[E] are evaluated exactly as if they were written ((B)this).I and ((B)this)[E], where B is the base class of the class or struct in which the construct occurs. Thus, base.I and base[E] correspond to this.I and this[E], except this is viewed as an instance of the base class.

[jveselka]

@Thaina base.base.Something() is a terrible idea. It breaks inheritance chain. You should consider switching your parent to whatever base.base is whenever you feel like you need that.

[jnm2]

@Thaina If you need to call a base method from outside of a child class, where you can't use the base keyword, then you'll need to extract the contents of the base method into a new public method.

[Thaina]

Sometimes work with 3rd party dll so no way to modified things like that

[jnm2]

@Thaina Are both the base class and its base class defined in the 3rd party dll?

[Thaina]

Something like that

[jnm2]

@Thaina If you're _even slightly_ the author of the base class or its base class, do not do this because it's a painful hack. But if there's absolutely no way to continue your project without it, you can use reflection to invoke the base base method implementation.

[jnm2]

@Thaina Keep in mind that inheritance works the way it does for a reason. We need it this way. We need to ability to write a base class that prevents you from running a base.base method. Of course you can subvert that with reflection just like you can subvert readonly, but once you go outside the language like that it's your funeral if you aren't extremely careful about it.

If there is a class that is poorly designed and accidentally prevents you from running needed base.base code, that should be an issue you bring up with the 3rd party library author asking for protected access to the extracted base.base method I was talking about earlier.

[Thaina]

@jnm2 I know all workaround we could do it just not satisfied when it not type safe

[jnm2]

@Thaina It can't ever be type safe. Your base class's base class has effectively said, whether on purpose or by accident, you may not call this method this way. If that's wrong, the solution is to refactor the base class's base class. Otherwise you're breaking the type safety rule which the base class's base class is enforcing (whether on purpose or by accident).

What you're requesting is pretty much the same as saying, "I know this library made this class internal, but I want a type-safe way to access it from my assembly." That's a contradiction in terms. Type safety _means_ not accessing a library internal class from your assembly.

Likewise, type safety also means _not invoking a base.base method implementation_. If it was otherwise, there would be no way for me (as the base class implementor) to prevent you from digging out of my level of abstraction to the base class beneath and subverting my logic, _as a public API_ no less.

[eyalsk]

@Thaina The more you know about the inheritance chain the more dependent on it you become; sometimes we want/try to _twist_ the language to fit our _bad_ design or _bad_ choices. :)