0

Subsequent to this question of mine C#8 interfaces with properties/methods defined in them - apparently not working, is it possible to use the "members in interfaces" feature without apparently introducing gaping type-holes that the necessary casting (described in the accepted answer) seems to create?

If dangerous casting is needed for that, it seems potentially a greater liability than an asset.

user3779002
  • 566
  • 4
  • 17
  • Not sure why this is creating a "gaping type-hole", can you elaborate? Why do you consider casting an object to its interface dangerous? – Lasse V. Karlsen Jan 14 '22 at 10:40
  • 1
    The feature is notoriously mis-understood. It was designed as a refactoring tool, being able to change an interface even though it gets used in an assembly that cannot be changed anymore. The default interface method/property keeps such an assembly usable. Used the feature as intended, casting is never necessary. – Hans Passant Jan 14 '22 at 10:54
  • @LasseV.Karlsen: Per type hole, it's literally all in the other question. "Why .. casting an object to its interface dangerous?" Because you're overriding C#'s static typing is why. If you get it right (object has that interface), fine, if wrong (object does not have that interface) you have introduced a run-time error. Unless I'm mistaken - hence this question. – user3779002 Jan 14 '22 at 10:54
  • But through inheritance the object *could* have that interface, even if the actual type you're currently writing code in doesn't. However, if you make the type sealed, you'll get a compiler error. And it is not difficult to write code that will fail at runtime so this is just one other thing to be aware of, not sure I'd categorize this as dangerous, or all sorts of things you can do would be dangerous as well. – Lasse V. Karlsen Jan 14 '22 at 10:58
  • Additionally, if the class is supposed to have that method, don't declare it as a interface method with a default implementation, just declare it normally and implement it in the class and it is available for you in the class as well. It wasn't meant to be another way of declaring methods and properties on objects, it was meant to be able for library developers containing interfaces to retroactively add stuff to those interfaces, where implementations are in other assemblies that you cannot change, without breaking runtime loading of those types. So used correctly there is no danger – Lasse V. Karlsen Jan 14 '22 at 11:00
  • @HansPassant: That's very interesting but I'm still lost - can you elaborate how it can be used without casting because that seems fundamental to it's use - in MS's own docs on interface methods it says "That cast from SampleCustomer to ICustomer is necessary". How can they be used without casting? Some links would be great, thanks. – user3779002 Jan 14 '22 at 11:10
  • @LasseV.Karlsen: I'm writing a compiler, a pretty substantial amount of work. I rely on the type system. "it is not difficult to write code that will fail at runtime" I've had maybe 4 run-time crashes in 11 month's development, all my doing. I don't need a new way of adding more. – user3779002 Jan 14 '22 at 11:11
  • @LasseV.Karlsen: Further (can't edit comment) - if methods don't follow a single class hierarchy, as they don't here, sticking them in the base class is worse than useless. Hence mixins – user3779002 Jan 14 '22 at 11:17
  • You can't use the interface-only methods *in the class* without casting to the interface. That's not possible, but the feature wasn't meant to allow that either. It was, as I said, for authors of interfaces to be able to add new features to *their* interfaces that other authors haven't implemented, without causing issues loading assemblies with existing implementations. It wasn't meant to be "mixins". – Lasse V. Karlsen Jan 14 '22 at 11:24
  • If someone would care to summarise this into an answer, I'll accept it. – user3779002 Jan 16 '22 at 12:40

0 Answers0