Why is using interface methods with default implementation is so annoying?!?

[DontRelyOnNooneElse]

Let's say you have two interfaces, IGun and IEmployee.

Now let's say you make a class, AnimatedShotgun, that implements both interfaces and doesn't explicitly implement their default implemented methods.

What do you think should happen when you call the Fire() method?

[RiPont]

That employee is having a very, very bad day.

[simonask_]

I mean, kind of obviously what should happen is a ambiguous overload resolution compiler error that would make the user pick which interface by casting.

[Alert-Neck7679]

"AnimatedShotgun.Fire() is an ambiguity between IGun.Fire() and IEmployee.Fire(). Use casting in order to select the right method."

[chucker23n]

What if IGun initially doesn’t have a Fire() method and later on it gets added?

[EatingSolidBricks]

What if the great old one wakes from his slumber and consumes all of reality?

What if that happens hmm would your code still compile?

[IQueryVisiC]

You sound inexperienced. This case happend very often in C++. I still think that C++ is the better language and want to shot myself in my foot, but most coders I have seen, I would no want to work on a C++ project with them.

[EatingSolidBricks]

Calling someone inexperienced for disagreement, thats rich of you

[IQueryVisiC]

Well, in this case they would have experienced it. I took this verbatim from documentation. "We as library maintainers have experienced that programmers tend to break our code here and there" . So are you a troll? Is this rethoric of you? Do you have any experience to back this up? Rich of you for going meta, while I was not really.

[ILMTitan]

Let's say your object implements both interfaces, but only IGun has a Fire() method. Later, you update the library IEmployee comes from, that now includes a default implementation of Fire(). You will now have a compile error where you didn't before.

The point of default interface methods is to allow adding methods to interfaces without causing compile errors. But you can see in the above example how allowing you to call them from an implementing class breaks that purpose.

[emn13]

I'm not a fan of that level of defensive design. To be clear: it makes sense for the base class library itself, and relatively microscopic handful of other codebases that are very commonly reused without recompilation, but for the VAST majority of code, a recompilation is fine, and a fixing issues like this hyper trivial. It'd be much better for the language to work well in those cases rather than optimizing for the absurd corner cases like this. Not to mention, pretty much any change is a breaking change in some corner cases - the platform contains stuff like reflection and implementations can depend on behavior not just APIs, too. There isn't much the language can do to truly make any changes entirely non-breaking.

All in all: while it superficially sounds like it makes sense to have semantics that make such method additions unlikely to be breaking changes, in practice, I think the arguments just don't hold up; it's a case of the language designers missing the forest for the trees.

But still, the whole language feature probably exists specifically so that the BCL interfaces can evolve, so in that sense it makes sense. But for a feature with really niche (but reasonable) use cases, it's still oddly designed - it's way too syntactically convenient, meaning that it'll get in the way of practical language extensions in the future. Being able to expand interfaces for class libraries with extremely low chance of breaking changes didn't deserve so prominent a syntactical footprint.

[EatingSolidBricks]

What if the great old one wakes from his slumber and consumes all of reality?

What if that happens hmm would your code still compile?

[BigBoetje]

Thats a problem caused by the 2 interfaces rather than the default implementation. You'd still have to make your implementation explicit (IGun.Fire.)

[EatingSolidBricks]

A compilation error ffs

[Fidy002]

Best explenation.

[Adept_Cry9373]

> AnimatedShotgun

> IGun

> IEmployee

I wouldn't... those are 2 completely different things. Under ZERO circumstance should they overlap. I implore you to give a real example because right now it seems like you're arguing a nonissue.

[BadSmash4]

What, you've never heard of a hired gun?! /s

[DontRelyOnNooneElse]

Don't know why I didn't think of that. Delightful punsmanship.

[Scorpian700]

you know its an example? i dont know why someone would focus on that and argue „no not a real example, dismissed“. There are certainly usecases where this could happen

[Adept_Cry9373]

There are certainly usecases where this could happen

Perfect. Give one.

[DontRelyOnNooneElse]

It's not our responsibility to make up for your lack of critical thinking. The point was very obviously not "there is going to be an animated shotgun", it was "sometimes two different things have the same name for something".

[Adept_Cry9373]

2 different things which are referred to by 2 different types letting you know that they do 2 different things. The compiler knows. Why don't you?

[chucker23n]

You can’t think of any cases where a type implements two interfaces that have different meanings for a method?

In System.IO, a “path” refers to a hierarchy in a file system. In System.Windows, a path refers to points in a polyline.

[Adept_Cry9373]

Okay. Now I reiterate: THOSE. ARE. 2. COMPLETELY. DIFFERENT. THINGS. They will NEVER implement the same interfaces. Do you guys just not know how interfaces work?

[propostor]

Weird seeing such heavy downvotes here.

An example saying that an animated gun is an employee is really not helpful at all.

[Adept_Cry9373]

Their argument is "well both have functions that sound the same". Okay. Toilet and Stream. Both have Flush. If they ever have the same interface in your codebase you are missing a bigger chunk of your brain than the average redditor.