Method Hiding Apologia

re: Method Hiding Apologia

Jeremy S. Pederson — Thu, 10 Mar 2011 06:37:55 GMT

I personally like this feature... backwards compatibility

//old communication object

internal class CommunicationObject : ICommunicationObject

{

public CommunicationObject(ISomeInterface someInterface)

{

this.ISomeInterface = someInterface;

}

protected ISomeInterface { get; private set; }

}

//new, more advanced, communication object

internal class CommunicationObjectEx : CommunicationObject, ICommunicationObjectEx

{

public CommunicationObjectEx(ISomeInterfaceEx someInterface)

: base(someInterface) { }

new protected ISomeInterfaceEx SomeInterface

{

get { return base.SomeInterface as ISomeInterfaceEx; }

}

//public facing factory

public static CommunicationObjectFactory

{

//old factory method

public static ICommunicationObject CreateCommunicationObject()

{

return new CommunicationObjectEx(new SomeClassEx());

}

//new factory method that lets the caller initialize a new version of the communication object without breaking old code

public static ICommunicationObjectEx CreateCommunicationObjectEx()

{

return new CommunicationObjectEx(new SomeClassEx());

}

re: Method Hiding Apologia

Ralph Compton — Mon, 03 Aug 2009 17:59:54 GMT

I still don't see why the language includes both method overriding and hiding. Can this be explained without a reference to covariance?

re: Method Hiding Apologia

Brian Russo — Thu, 19 Feb 2009 10:37:37 GMT

I think this is a fairly decent article.. but frankly I'm not sold on method hiding at all.

I understand there could be situations where one can make use of method hiding; but it seems pretty non-intuitive by breaking how people expect polymorphism and your API to work.

I won't say I'll never use it.. but I hope I never do; because it seems that if you're having to do a lot of funky method hiding then your object hierarchy is probably pretty hosed.

Bottom line I just see very little advantage to using method hiding over method overriding. The latter is much more intuitive and is how most people expect things to work. The examples given are relatively simple yet still somewhat confusing - I don't even want to think how much damage you could do by hiding methods in larger chunks of code.

cheers,

- bri

re: Method Hiding Apologia

Nick — Wed, 05 Nov 2008 12:06:20 GMT

Personally, programming is not about creating frankenstein concepts. This cake example in my view demonstrates exactly how not to use these concepts. Consider the scenario when a programmer (possibly new to the project) is tasked with calculating tax on a bunch of items, and creates a list of generic groceries, only to calculate the wrong tax because of the frankenstein relationships. Programming is hard enough right?

re: Method Hiding Apologia

David Nelson — Sat, 26 Jul 2008 00:29:31 GMT

@Konstantin,

The reason IEnumerable<T> needs to implement IEnumerable but doesn't need to worry about implementing IEnumerable<object> is so that a reference to IEnumerable<T> can be used with code that pre-dates generics. For example:

public void OldFoo(IEnumerable bars)

{

// ...

}

public void NewFoo<T>(IEnumerable<T> bars)

{

// This doesn't work if IEnumerable<T> doesn't implement IEnumerable

OldFoo(bars);

}

While you could say the same thing about IEnumerable<object>, there are well known ways around that problem (using generic methods instead of IEnumerable<object>, for example), whereas with pre-generic code the only workaround is writing a wrapper class. Also, generic covariance, if it ever gets added to the language, will take care of the IEnumerable<object> problem, whereas it can't take care of the IEnumerable problem since they are two different types.

re: Method Hiding Apologia

Alex Grenier — Thu, 03 Jul 2008 22:28:00 GMT

To me, the usefulness of hiding is to change the result of a method call based on which subtype it gets casted to. This is a good way to "downgrade specialization". Think of a scenario where such a type gets passed to methods where the parameter may be defined as type A or type B - thus altering the behavior of the passed object.

re: Method Hiding Apologia

Konstantin Triger — Tue, 01 Jul 2008 10:23:05 GMT

To Joshua:

Thanks for your comments!

I think all this thread is a "post mortem" analysis. Clearly we won't be able to remove this feature. Yet we want understand whether it was the right thing to do, so we will be able to recommend better practices, add FxCop rules etc.

The main point of my post is that Extension methods could give a reasonable solution to the problem, if and only if the compiler would make them to precede in name resolution chain, i.e.:

class Y {

public void test() {

Console.WriteLine("Y");

}

class X : Y {

public void testEx() {

Console.WriteLine("X");

}

//declared by the user in the user code!

static class ExtensionX {

public static void test(this X x) {

x.testEx();

}

...

new X().test(); // -> 'X' is printed (currently the output is 'Y')

So the user will be able to call a 'simpler' extension method.

About my and your #3 P.S.: Following your logic IEnumerable<T> should be also IEnumerable<object>, which is not the case. If due to some reason you need to convert your IEnumerable<T> to IEnumerable, one way would be a method like this:

public static IEnumerable ToGenericIEnumerable<T>(IEnumerable<T> e) {

foreach (T t in e)

yield return t;

}

Of course that's not needed, since IEnumerable<T> derives from IEnumerable, but what would you do if you needed to convert IEnumerable<T> to IEnumerable<X>, provided T derives from X?

re: Method Hiding Apologia

Joshua — Mon, 30 Jun 2008 20:37:27 GMT

Konstantin Triger,

Method hiding is already part of the C# specification, so it is here to stay unless it proves to be used by no one. (Since the CLR uses it, that is not likely)

Extension methods should be created with naming schemes that avoid that possibility as much as possible. Try for instance using less common verbs for what you are doing. So AquireData rather then GetData, that way you get the definition you want, and the peace of mind that there is a low chance that the underlying developers would likely choose the simpler word over the more "complex" one.

Warning on extension method hiding would be nice, although I suspect that it will be coming in a future version.

About your #3 P.S., IEnumerable<T> is an enumerable of objects, it just also happens to be an enumerable of T's, not having it inherit from IEnumerable would not make logical sense, shouldn't an enumerable of T be able to treated as an enumerable of objects?

Javier,

They have similar issues, but method hiding requires active work to get to be extremely complex (After all it is designed to be used sparingly), compared to polymorphism's ability to quickly mess up everything if one of your parent classes adds a new method that matches the other parent.

re: Method Hiding Apologia

Javier — Sun, 22 Jun 2008 03:26:42 GMT

How is method hiding different from polimorphism?

re: Method Hiding Apologia

Konstantin Triger — Sat, 31 May 2008 19:13:00 GMT

I think the method hiding feature is very useful, yet I think it should not get into the language.

The reason is because it's a _client_ feature. In other words, if the client is already compiled, replacing the server will not affect the client behavior...

In this view 'method hiding' is very similar to 'default parameters' feature, which, as far I know, was not included into the language because of the very same reason.

So what is the solution? In my opinion it's extension methods, implemented by the _client_, while the server make all its methods unambiguous.

Thus my operational proposition is to make extension methods _precede_ class methods in resolution chain, letting the above suggestion possible.

P.S.

1. The fact that if I have an extension method ambiguous with the class method, it simply disappears (no warning or similar) looks buggy (csc 3.5).

2. Having a possibility to implement the same interface several times along the class derivation chain actually is an instance of the same 'feature'. Since it's used a lot in .Net BCL, as mono contributor I several times fixed bugs caused by different implementation of the same interface along the chain.

3. Q: what about IEnumerable<T>, it does not fit with the guidelines. A: To my opinion IEnumerable<T> shouldn't derive from IEnumerable. In general, derivation for hiding looks problematic to me due to very hard runtime bugs, which it enables.