[Feature Request] Interfaces: attribute signature support

[halittiryaki]

Having an AOP approach for a specific task, I thought of having a feature in C#, which would allow me already in the architectural design to assert that a type implementing a specific interface contains a member that matches the signature by attribute and member type only without knowing the actual name of the member.

given a simple example:

interface IWillBeFound
{

  [TargetMethodByInterfaceAttribute]
  void *(*);

}

class Foo : IWillBeFound
{

  [TargetMethodByInterfaceAttribute]
  void DoSomethingUsefulOnMyOwn(string text)
  {
    Bar(text);
  }

}

without such a feature, checks whether a member with the expected attribute exists can be done on runtime, hence no compile time errors.

as mentioned, I came across this idea in designing an AOP approach module implementation. But I think it would be in general definitely a nice feature fitting just great into the already very advanced dynamic feature set of C# targeting 'intelligent' modularity of applications.

[jnm2]

If I have an object and all I know about it is that it is an IWillBeFound, how do I call the method?

[HaloFour]

What is an actual use case for this? How do you propose any of this actually work in the CLR? Members require names. Interface implementation requires overrides to be set at compile time in the IL metadata.

[bondsbw]

Is this just intended to be syntax sugar for reflection, e.g. if (foo is IWillBeFound)?

Making it an interface pushes it beyond simple reflection and would affect overload resolution, generic type parameter constraints, and more which would require CLR changes (as @HaloFour alluded to).

Perhaps #807 can inspire a different way to achieve that goal:

if (foo.DoSomethingUsefulOnMyOwn(string) is [TargetMethodByInterfaceAttribute])

[halittiryaki]

@jnm2
(AOP = Aspect Oriented Programming)
You are thinking OOP.

Its not only an IWillBeFound. It's an IWillBeFound which will HAVE TO have a method that wants to be targeted for invocation by an AOP injection which is marked with a [TargetMethodByInterfaceAttribute].

as an example of how calls to such methods can take place in AOP, check: aspectize

@HaloFour
In my use case its too complex to go through it here, but a simple use case could be a logger module, which simply 'docks' to the current code base without big changes.

eg:

interface ILoggable
{

  string LogName { get; }

  [WriteLog]
  void *(*);

}

public class Car : ILoggable
{

  public string Name { get; set; }

  public string ILoggable.LogName
  {
    get { return string.Format("Car.{0}", Name); }
  }

  [WriteLog]
  public void Move(int meters)
  {
    //AOP Module will inject a logwrite-beginn call here with Member name as appendix
    
    // Do Some Stuff

    //AOP Module will inject a logwrite-end call here with Member name as appendix
  }
 
  public void Save()
  {
    // Do Some Stuff
  }

  [WriteLog]
  public void Delete()
  {
    //AOP Module will inject a logwrite-beginn call here with Member name as appendix
    
    // Do Some Stuff

    //AOP Module will inject a logwrite-end call here with Member name as appendix
  }

}

// COMPILE Error! Programm does not implement Interface Member with Attribute [WriteLog]
public class Truck : ILoggable
{

  public string Name { get; set; }

  public string ILoggable.LogName
  {
    get { return string.Format("Truck.{0}", Name); }
  }

  public void Move(int meters)
  {
    // Do Some Stuff
  }
 
  public void Save()
  {
    // Do Some Stuff
  }

  public void Delete()
  {
    // Do Some Stuff
  }

}

[svick]

@halittiryaki I think that's not what interfaces are for. And if you want to have custom diagnostics, I think the right way is to create a custom diagnostic analyzer, not try to make the compiler do the work for you (which it will never do perfectly).

[HaloFour]

@halittiryaki

I don't think that it's helpful trying to mix aspects and interfaces. They have very different concepts.

None of this explains how you intend for this to work in the CLR, or how any of the AOP logic is actually injected into the methods.

The LDM has discussed AOP scenarios before and the proposal intended to handle that is source generators, #107.

[halittiryaki]

@svick
No its not about custom diagnostics. maybe you meant code analysis? Its simply about (very) dynamic modularity.

@HaloFour
For my understanding the core concept of Interfaces is to have a partial blueprint of a type that the architectural design can rely on, so finally the clr. Because the type in question will interfere with outer code via the members in question. That's it. The Architect makes sure the developer implements the stuff properly and the compiler helps both achieving this. No mixing of different concepts for my understanding at all. Meaning that conceptionally ALL code in interfaces dont have to be necessarily translated to IL. A void *(*); makes no sense on that level in any means.

As you (with source generation) and @svick (with code analysis) pointed to the proper direction, it would be a Roslyn task, before IL generation happens.

To simply tell the developer:

you are not allowed to compile because Class Truck does not implement a Interface ILoggable method with [WriteLog]

As mentioned, this idea came when designing an AOP module but such a feature would most importantly, affect the way how developers think in general and get them into C# 's dynamic capabilities more deeply. And in turn, how C# continues to evolve in that field.

In my opinion, at the current stage of the C# development, the interface concept integration is still deeply derived from strict, very static OOP thinking. This is simply no more. Things are very dynamic and actually the .NET family as a whole is more and more going that direction too. So, just an idea for interfaces to go along the 'dynamic evolution' of languages in general.

But if you just miss the ability to invoke that function as it is defined in the interface (even if it doesn't mean it has to conceptionally), because you used to know it like that, technically there is nothing that would prevent a call like:

(car as ILoggable)[WriteLog]();

// instead

foreach (var method in (car as ILoggable).GetType().GetMethods()
        .Where(m => m.GetCustomAttributes(typeof(WriteLog), true).Length > 0 && m.GetParameters().Count() == 0)
  method.Invoke(car, null);

thanks for the link, some interesting stuff there.

[Joe4evr]

To simply tell the developer, "you are not allowed to compile because ILoggable does not implement a method with [WriteLog]"

Then why not name the method in the interface WriteLog()?

[svick]

@halittiryaki

To simply tell the developer:

you are not allowed to compile because Class Truck does not implement a Interface ILoggable method with [WriteLog]

That sounds a lot like something that could be achieved with a diagnostic analyzer. You would have to use existing syntax, but I don't think that would be an issue.

Why do you think this approach is not suitable and it has to be done by the compiler, with special syntax?

---

Also, keep in mind that C# is definitely not going to add features just to support one 3rd party AOP framework. You make it sound like this feature would be generally useful, but I'm not convinced it is.

[MkazemAkhgary]

sorry for my lack of knowledge, but I don't see anything mentioned about AOP in this wiki article about C#.

https://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29

anyway I took a quick look at below article, it sounds cool, you may want to try it.

https://www.codeproject.com/articles/12650/using-aop-in-c

[halittiryaki]

Then why not name the method in the interface WriteLog()?

are you serious asking this? that has nothing to do with dynamic modularity in complex scenarios.

when a class implements ILoggable with WriteLog() statically typed, a Car class looks like this:

class Car : ILoggable
{

  public string Name { get; set; }

  public string ILoggable.LogName
  {
    get { return string.Format("Car.{0}", Name); }
  }

  public void ILoggable.WriteLog(string msg)
  {
    // Do Some Stuff
  }
  
  public void Move(int meters)
  {
    WriteLog("start");
    // Do Some Stuff
    WriteLog("end");
  }
 
  public void Save()
  {
    // Do Some Stuff
  }

  public void Delete()
  {
    WriteLog("start");
    // Do Some Stuff
    WriteLog("end");
  }

}

This is very painful in terms of DRY. a module knows what to do as much as possible. this is primary school coding

[MkazemAkhgary]

void *(*); is just weird, I would say keep interface member signature the way it is void WriteLog(string msg);

then an attribute could be used somehow to do rest of work for you.

[halittiryaki]

@MkazemAkhgary thanks for the links.

this feature request is not about AOP at all.
But for your understanding, AOP is a way of engineering to achieve component oriented architecture.

[HaloFour]

@halittiryaki

No, that is not the core concept of interfaces. They very specifically are a contract to the consumer of the interface that the advertised members exist. That's it. They don't care how the members are implemented and they have nothing to do with reflection or attributes.

@svick is right, if your goal is to find a mechanism through which to enforce that members of a type are decorated with some attribute based on some arbitrary rules then the appropriate solution is to write an analyzer, which is already possible.

[halittiryaki]

@svick again, this issue has nothing to do with AOP directly. Just came across it by doing AOP.

I don't judge whether an interface paradigm such that will be useful in general for sure.
For my part, I definitely say this would be very useful in strong modular architectures.

Because than attributes would become signatures of interfaces as well, which they are actually, to wich I can rely on in the architecture already also. Not in the implementation, as it is now the case.

@HaloFour
that is what I'm saying. Nothing mentioned about HOW they are implemented or reflection.
But yes, one more time and to the final, with this issue, I'm proposing that Attributes become a signature for interfaces as well. Because in my opinion they are without doubt.

[jnm2]

I've seen this approach before. It comes to no good. This proposal is dead in the water unless the personal comments get lost and we can see a use case that interfaces can't handle and attributes can.

[halittiryaki]

@jnm2 then why continue the cause Behaviour?

[jnm2]

Because I'm an incurable optimist who thinks that calling out bad behavior when I see it and hoping for resolution is better than choosing to ignore the whole conversation.

[svick]

@halittiryaki

you will get a runtime exception, telling you: ... is not marked as serializable
with the feature proposed, you can't compile, because [Serializable] is missing.

That would be a breaking change, so it's not going to happen for the existing BinaryFormatter.

If you're designing a new serializer and are worried about this, you could use marker interface instead of marker attribute (or an interface & attribute combination, since that's the only one where this proposal would be useful).

In both cases, if your serializer has a requirement that's not expressible in the type system (like BinaryFormatter and the [Serializable] attribute), you could write a Roslyn Analyzer that checks it, no new syntax necessary. (And a similar analyzer already exists.)

[halittiryaki]

are you guys for real, or is this a playground for Microsoft's new AI chatbot program

[jnm2]

are you guys for real, or is this a playground for Microsoft's new AI chatbot program

The attacks are all coming from you, my friend. This is the least effective strategy if you have something to offer.

[halittiryaki]

@jnm2 no attacks man, in now way. just reflecting

he has brought the subject of the issue down to the serializer implementation itself. nevertheless, the link he provided is at least useful in showing that Microsoft is actually aware of the lack of such a feature in the language it self.

and btw. Im offering nothing nor I'm selling you something. just a proposal from dev to dev, from my perspective at least. not expecting anything for it.

[jnm2]

no attacks man, in now way. just reflecting

Then maybe you aren't seeing it from the outside perspective. This is a personal insult: "are you guys for real, or is this a playground for Microsoft's new AI chatbot program" and it fits anyone's definition of verbal attack.

just a proposal from dev to dev

Let me rephrase: This is the least effective strategy if you have something to propose, from dev to dev.

Their ask is simple. Would you please show us how this proposal allows us to do something we couldn't do before? Or show us how it relieves existing pain on a large enough scale to warrant the added language and runtime maintenance, and the mental complexity imposed on ordinary language users?

It's not an inherently good thing to have two ways to do the same thing. It's an inherently bad thing. So far we can't see how this is not just another way to do what interfaces already do. Show us.

[halittiryaki]

I showed 2 examples at least, where current interfaces cant handle them.

now, lets try it this way. to keep the most simple case, show me a way to handle the [Serializable]
problem with current interface paradigm. because you claim it does, even if I proved that it is not:

So far we can't see how this is not just another way to do what interfaces already do

[bondsbw]

Ok, so the point is to guarantee the existence of members with a specific attribute whose signature fits a specific pattern, in order to be able to invoke the member.

So again, it is fundamental to define how that works when in situations the language doesn't currently support, such as multiple matches. Otherwise the feature seems useless compared with interfaces as they already exist, which already cover single match cases.

[yaakov-h]

I still don't get the point of this.

It sounds like you're trying to have interfaces without naming the members, then putting a name in some attribute.

We already have a feature in the C# language today which allows you to name the members of interfaces. It works the same for interfaces, classes, structs, and will almost certainly also work the same way for shapes as well.

It's a well-cited saying around here that every feature proposal starts with negative 100 'points', and it's up to the proposal to bring it to 100 'points' of value.

So far, I see absolutely no use case for mucking around with interfaces in this manner.

Please:

1. Cut the personal attacks.
2. Flesh out the proposal in more detail. There are some very obvious oversights here, such as:
   • Implementing classes could define multiple matching members (with the same signature and attribute). How do you choose one? Or, would you invoke both? If so, what about when the method return a value?
   • How would you invoke such a member in C#?
   • How would you invoke such a member in another CLR language such as VB and F#? You may need matching language proposals there.
3. Provide some concrete use-cases. How would you actually use this feature, if it existed, and why does the current language definition make this either too cumbersome, or outright impossible?

So far, all I can see in this thread is a very up-in-the-air idea, and vitriol. Cut the latter, and make the former more concrete. As it stands now, I cannot imagine anyone from the language design team wanting to champion this.

[HaloFour]

@halittiryaki

public class Foo : ISerializable { ... }

public class Bar : Foo { ... }

Is Bar serializable? By virtue of the fact that interface implementation is inherited it has to be. But that doesn't mean that it is. This is a failing in the Java model for serialization which is managed via marker interfaces rather than by attributes/annotation. Your proposal suffers from the same failing. Interfaces aren't a good vehicle for this kind of compiler enforced declarative programming, and they make even less sense in the context of AOP.

[iam3yal]

Without thinking so much about it but reading through briefly why you need to change the language when we can have something like this?

void Main()
{
	Car car = new Car();
	
	car.DoSomethingUsefulOnMyOwn();
}


interface ILoggable
{
	string LogName { get; }
}

// Special Attribute? might not be needed. 
abstract class AOPAttribute : Attribute
{
	public virtual void PreInjection(object source)
	{
	}

	public virtual void PostInjection(object source)
	{
	}
}

class MyAOPLogger : AOPAttribute
{
	public override void PreInjection(object source)
	{
		ILoggable logger = (ILoggable)source;
		
		Console.WriteLine(logger.LogName);
	}

	public override void PostInjection(object source)
	{
		ILoggable logger = (ILoggable)source;
		
		Debug.WriteLine(logger.LogName);
	}
}

class Car : ILoggable
{
	private readonly MyAOPLogger _logger = new MyAOPLogger(); // Compiler generated;
	
	[MyAOPLogger]
	public void DoSomethingUsefulOnMyOwn()
	{
		_logger.PreInjection(this); // Compiler generated;
		
		// Do somestuff
		
		_logger.PostInjection(this); // Compiler generated;
	}
	
	public string Name { get; set; } = "Unknown";

	string ILoggable.LogName
	{
		get { return string.Format("Car.{0}", Name); }
	}
}

So maybe like @HaloFour pointed out it would be be possible to do that through source generators.

[halittiryaki]

Is Bar serializable?

if class Bar {} has the [Serializable] attribute, yes. nothing, absolutely nothing changes in that with this proposal. this is a task, which takes place in the implementation. the complexity in handling the level of the inheritance is the job of the serializer libs implementation. this proposal, in the case of the serializer implementaion, would allow the serializer implementation to be 100% sure that the incoming object instance to be serialized is marked as [Serializable] at least in 1 place in the inheritance ladder.

but, also this complexity which at the moment takes place in the implementation, whether the given instance is declaring the [Serializable] attribute at the outer most type could be stripped away just by declaration with this kind of interface paradigm. eg:

interface ISerializable 
  requires explicit [ISerializable] //-> telling the most outer Type has to declare it.
{}

interface ISerializable 
  requires [ISerializable] //-> the instance will be serialized down the ladder where the attribute was placed
{}

the decision is made by the architect in design process, not the coder in implementing the serializer.

By virtue of the fact that interface implementation is inherited it has to be.

fail. power of attributes

This is a failing in the Java model for serialization which is managed via marker interfaces rather than by attributes/annotation.

So basically you are pointing out that this proposal would be a kik butt feature on Java. As it will keep the benefit of solving this issue by the usage of attributes AND now would be bringing the architectural benefit of using Interfaces for this kind of scenarios as Java engineers did.

Your proposal suffers from the same failing.

fail, once more.

Interfaces aren't a good vehicle for this kind of compiler enforced declarative programming,

?! interfaces are composed of declarations, nothing else and are compiler enforced.
you know of interfaces with actual implementations and are enforced on runtime? tell me

and they make even less sense in the context of AOP.

the weirdness.. constantly bashing and trashing based on non sense. endless loop

one might have a look at what this all implies in the actual implementation in the very ordinary and so easy to understand case of the serializer.
BinaryObjectInfo
FormatterServices

code / complexity regarding the [Serializable] / ISerializable there just serving as checks and redirects, gets useless and obsolete, would there have been a language feature as proposed. Also for the consumer, which is the most important part and the reason why C# preferred the attributes way. instead of interfaces like in java for the benefit of architecture and design.
now with this proposal, you get both worlds handled.

in respect to the proposed issue, just proceed as follows:

• Verify, discuss the question: Are attributes signatures? Here in the forum. because this is everything this issue/proposal is about in its core.
• Let the csharp design team pick up this question as well. Let them have it sorted out. in coffee / cigarette breaks, whatever..
• if they come to the conclusion in conjunction with opinions made here, that attributes are signatures, they will find a way 99% to engineer this smoothly into the language. because only they (or people who are aware of every corner in the language design, but not necessarily in the implementation) will sort out a draft as a proposal how this could be 'championed' into the language.

my part here is to raise the fundamental question, which proposes a feature in the language.

Are attributes signatures?

[DavidArno]

Are attributes signatures?

No. Two methods with the same name and parameters, but different attributes, have the same signature.

Therefore attributes are not signatures. That was easy.

Oh and you have something else very wrong too: coders design; compilers implement. This misunderstanding on your part seems to have sent you down a rabbit hole over attributes. Time to stop digging and climb on out.

?! interfaces are composed of declarations, nothing else and are compiler enforced.

You might want to have a read of #52. As of C# 8, interfaces will never be the same again...