Add new interface modifiers hasa and isa

[digitalpowers]

As I design libraries in my daily work I realize there are 2 reasons I make a public interface.
First is for consumers of the library to depend upon and second for consumers of the library to modify the default behavior in various ways or extension points, whatever you want to say.

However, it can be confusing when picking up a new library, it is hard to know what interfaces here am I supposed to use and which am I supposed to implement. We largely solve these problems by documenting things and that works okay.

However I propose we add new public modifiers to the language for interfaces, isa and hasa.

public-isa interfaces would be a normal public interface with the additional requirement that you can only implement it, you cannot depend on it (possibly with the exception of depending on one within a class that is implementing one for chain of responsibility type patterns.

The public-hasa modifier would allow depending on the interface but not implementing it.

The tools would then be able to help identify interfaces for various purposes from a library you have referenced to help you come up to speed faster/better and the documentation becomes more implicit.

I would expect interfaces using isa/hasa to allow the assembly they were declared in to use them in any way just as if they were internal/public.

Thanks for listening, please help me understand why this is a good/bad idea!

[CyrusNajmabadi]

@digitalpowers you could get this today by defining your own "HasAAttribute" and "IsAAttribute", and then writing analyzers that ship with your library that then checked for these special rules of yours.

[HaloFour]

First is for consumers of the library to depend upon and second for consumers of the library to modify the default behavior in various ways or extension points, whatever you want to say.

I'm not sure why these are two different things or why they would rely on two different mechanisms. Could you provide use cases for these "has-a" interfaces? If they're there strictly for the purposes of metadata and documentation why wouldn't attributes suffice?

[CyrusNajmabadi]

Note: the above is a way you could achieve the functionality you're asking for. Then next question is: is this a good idea or not?

IMO, no. One of the key things you said was: "The public-hasa modifier would allow depending on the interface but not implementing it."

This it not a concept that makes any sort of sense to me and indicates that something is rotten in the state of denmark :). If you are using an interface, it is precisely to say: "i do not care about the implementation. all that matters is you abide by this contract."

If you want to prevent someone from being able to implement something, there are already ways of doing that. For example, just having a base class with an internal constructor that they can then not derive from. In this case, you care about the implementation, and are thus exposing it, precisely to control how others implement things.

[digitalpowers]

fair enough, i will look into analyzers right now, seems like a potentially useful feature still though, or am i a bit off base?

[digitalpowers]

@HaloFour im thinking from a dependency injection standpoint, any library should provide me interfaces for me to consume to call methods on etc that are the mechanism by which i access the libraries implementation, which is what I was calling hasa interfaces. I want to have one of them and use it to do stuff.

The other common thing when making a library is to provide interfaces that are expected to be implemented if you want to change the behavior of something the library is doing.

Its not that implementing a hasa interface is terrible its just that it isn't terribly useful, and depending on an isa interface doesn't help much either because if you haven't implemented it to change the libraries behavior then no one has likely provided an implementation.

[HaloFour]

@digitalpowers

It sounds like you're describing a difference between being a consumer of an interface vs. an implementer. But in both cases a normal interface still sounds like the normal approach. Could you provide a concrete example as to why you don't think that is the case for this configuration case?

[bondsbw]

#485 is related. closed is effectively hasa for classes. It could only be derived/implemented within the same assembly, and is sealed elsewhere.

[svick]

This sounds similar to the InternalImplementationOnly proposal (dotnet/roslyn#220) that seems to have been rejected.

[YairHalberstadt]

Both hasa and isa will make testing difficult, as you will want to implement an interface you consume during testing, or test an interface you implement.

[AustinBryan]

This seems like a really bad idea and will cause a lot of pain. At some point, you are going to want to depend on and "have-a" interface, and making it is-a will just be really frustrating, especially if you didn't write the code and therefore can't change it. Also, how would you be able to pass it to functions to have functions do something with it?

The hasa modifier sounds basically the same as sealed. A sealed interface makes just about as much sense as a sealed abstract class. You can't instantiate the interface by itself. The whole point of an interface is to implement it, and this would be entirely defeating the point of it.

[digitalpowers]

@YairHalberstadt We could always have an attribute like InternalsVisibleToAttribute for isa/hasa or just use the same attribute since it is clearly the same need.

@every one else fair enough I think the general concensus is that this is a bad idea. I think for my needs I will make an attribute and an analyzer. Thanks for the discussion :)