Method Attribute Inheritance from Interfaces...  
Author Message
Dorfer





PostPosted: Visual C# Language, Method Attribute Inheritance from Interfaces... Top

...is it possible Sure doesn't seem to be. Consider the application outline below:

interface MyInterface
{
[MyAttribute("some vlaue")]
void DoSomething();
}

class MyClass : MyInterface
{
public void DoSomething()
{
}
}

Now, it sure would be helpful if I could access that attribute on the class, but no, we get a big "false" from calls like this:

Attribute.IsDefined(typeof(MyClass).GetMethod("DoSomething"), typeof(MyAttribute), true);

So, I guess I just wanted to confirm that this is in fact the case and I am not just doing something stupid... and if anyone has a good explaination for the behavior that could be entertaining too.

As far as a workaround goes I started looking into reflection to grab all interfaces on the type and go through them looking for my custom attributes but that got messy quick... worst case though I suppose I could work through it, I am just feeling particularly lazy at the moment and wanted to see if anyone else had a comment on the matter.




Visual C#6  
 
 
Mark Benningfield





PostPosted: Visual C# Language, Method Attribute Inheritance from Interfaces... Top

Hello All.

Dorfer:

I'll admit that I've never run across this before, but I wouldn't expect it to work. I mean, using attributes is a form of implementation by declaration, and the whole point of interfaces is that there is no implementation. None. So I would expect that wherever the interface was implemented, that would be the place for the declarative attributes.

Think about it. Attributes declare implementation (by way of metadata) right at the point they are declared, and on an interface member, there's nothing there but a hole to be filled by the implementing class. You can't declare metadata on a hole. Well, you can, but it obviously doesn't do any good.

HTH.



 
 
Nimrand





PostPosted: Visual C# Language, Method Attribute Inheritance from Interfaces... Top

Actually, I believe the problem is that MyClass.DoSomething and MyInterface.DoSomething are totally seperate methods that do not inherit from each other, even though the later is implemented by the former. Implementation != inheritence. However, if MyInterface were an abstract class and DoSomething an abstract method, I believe this would work. The distinction becomes more clear when you consider the scenario of implementing multiple interfaces at once. It is possible for a class's member to implement a member from two different interfaces at the same time. So, the method cannot inherit attributes from the interface, because it would have to inherit them from multiple interfaces.
 
 
Dorfer





PostPosted: Visual C# Language, Method Attribute Inheritance from Interfaces... Top

Mark,

First off you should know I understand your arguments and agree for the most part. The original problem is also no longer a problem, I just want to play the devil's advocate a little.

You said "using attributes is a form of implementation by declaration" -- I agree, but what you implied was that the declaration that was happening was part of the class and so since interfaces don't actually implement anything this would be invalid. I hold that attributes are a form of implementation of metadata which by definition is data about some part of the class not actually that item itself.

Another way to think of interfaces that I find commonly espoused by teachers in the field is that they are a contract. The various clauses in the contract then require implementing parties to provide certain functions. In this analogy I see attributes on interfaces like an extension of the definition of a clause. Not only do I provide a method signature, but I provide even more information (metadata) describing the purpose of a given part of the contract. I am in no way attempting to implement the contract, just giving more static description of a certain clause.

This is where your comment of "there's nothing but a hole waiting to be filled" comes in; yes, there is nothing but a hole, but that shouldn't mean I can't make comments on what should be used to fill the hole. Let's think of metadata in a different context; say on a variable. That variable may or may not have a valid value actually stored in it, but that should not prevent or enable the describing of metadata about the variable itself.

I think that is the point where our understanding differs. You are viewing metadata as describing the data stored while I consider it to be about the abstract storage medium. You see it as about the method "guts" so to speak while I consider it more an extension of the signature, a comment about the method (or class, or whatever) itself not the internals that make it up.

To wrap it up I will give an example of where my definition might make a lot of sense; this situation is very close to my original problem in fact. Basically, imagine I have a rather large c# application. Now, I want to integrate a scripting engine to allow command line access to run simple things. For this scripting engine I can "register" methods on objects with it to provide shortcut access; eg if I register the quit method on my main object as "quit" then all I do is type "quit" from the console interface to the script engine. Now, to register all the shortcuts I need I could manually go through and statically type them in, but that sure sounds ugly. Instead I come up with an attribute which I put on all the methods I want to shortcut into the script engine. This works wonderfully. Now, I want to make things nice and abstract so I extract interfaces out of most of my classes, for example IScriptHost is used instead of ScriptHost directly. Now, since all implementing classes of IScriptHost should expose some of their methods to the script engine I put the attributes on the interface instead of in the class. Bam! no luck.

 
 
Dorfer





PostPosted: Visual C# Language, Method Attribute Inheritance from Interfaces... Top

 
Actually, I believe the problem is that MyClass.DoSomething and MyInterface.DoSomething are totally seperate methods that do not inherit from each other, even though the later is implemented by the former. Implementation != inheritence. However, if MyInterface were an abstract class and DoSomething an abstract method, I believe this would work. The distinction becomes more clear when you consider the scenario of implementing multiple interfaces at once. It is possible for a class's member to implement a member from two different interfaces at the same time. So, the method cannot inherit attributes from the interface, because it would have to inherit them from multiple interfaces.


I think you are right on with "Implementation != inheritance", and it does work with abstract classes, I tried that last night actually.

I can't agree with the reasoning you went on to describe though, multiple inheritance is not at all a problem. If a method implements a declaration from two different interfaces it naturally should have the metadata (attributes) of both, just stack 'em up, it's not like you can only have one attribute on a given item...  In the special case that "AllowMultiple" is set on an attribute applied to a method on two interfaces which you attempt to implement with one method in a class implementing both interfaces the compiler could easily catch that and you could easily fix it with explict interface method declarations.  It would also most likely indicate a problem in your design...

 
 
Mark Benningfield





PostPosted: Visual C# Language, Method Attribute Inheritance from Interfaces... Top

Hello All.

Dorfer:

Mark,

You said "using attributes is a form of implementation by declaration" -- I agree, but what you implied was that the declaration that was happening was part of the class and so since interfaces don't actually implement anything this would be invalid. I hold that attributes are a form of implementation of metadata which by definition is data about some part of the class not actually that item itself.

No, actually, quite the opposite. If the implementation were to be considered part of the class, then that would be where implementation belongs, as part of the class.


Another way to think of interfaces that I find commonly espoused by teachers in the field is that they are a contract. The various clauses in the contract then require implementing parties to provide certain functions. In this analogy I see attributes on interfaces like an extension of the definition of a clause. Not only do I provide a method signature, but I provide even more information (metadata) describing the purpose of a given part of the contract. I am in no way attempting to implement the contract, just giving more static description of a certain clause.

This is where your comment of "there's nothing but a hole waiting to be filled" comes in; yes, there is nothing but a hole, but that shouldn't mean I can't make comments on what should be used to fill the hole. Let's think of metadata in a different context; say on a variable. That variable may or may not have a valid value actually stored in it, but that should not prevent or enable the describing of metadata about the variable itself.

See, I would view these apects of an attribute on the interface members as attempts to influence the implementation by restricting it to preconceived details, which would have their origin in the definition of the interface.

That's what I mean by implementation by declaration. In effect, it would be saying that one could implement the interface, but that the implementation could not conflict with pre-conceived notions of: a) the purpose of the interface, or b) the approach used to implement the interface.

You see, I agree completely that inheritance != implementation. Unfortunately, one of the language aspects of C# is that people tend to associate multiple inheritance with interface implementation, because in C#, multiple inheritance can only be mimicked by multiple interface implementation. If inheritance were actually involved in interfaces, I would come closer to agreeing with you about making stipulations part of the interface.

I mean, if a class were actually receiving something from an interface, why not receive some stipulations about the clauses in the contract as well. But it doesn't receive anything. It simply agrees to provide the services in the contract to anyone who requests them. Any stipulations concerning those services affects how they are implemented, however slightly.

Do you see what I mean