Attributes on interface property not enforced on concrete class

[Steve K.]

I added a property to an interface like this:
<code>
public interface ISimpleAddress
{
[Bindable(BindableSupport.Yes)]
[EditorBrowsable(EditorBrowsableState.Always)]
string CarrierFax{ get; set; }
}
</code>

I was disappointed to see that when I implemented the interface:
1) Visual Studio Refactoring-Auto-Implement tool didn't add the attributes
2) If I omitted the attributes from the concrete class the compiler didn't
complain.

Why do interfaces allow attributes if they won't be enforced?

Anyone know?

 

[Jesse McGrew]

I added a property to an interface like this:
<code>
public interface ISimpleAddress
{
[Bindable(BindableSupport.Yes)]
[EditorBrowsable(EditorBrowsableState.Always)]
string CarrierFax{ get; set; }}

</code>

I was disappointed to see that when I implemented the interface:
1) Visual Studio Refactoring-Auto-Implement tool didn't add the attributes
2) If I omitted the attributes from the concrete class the compiler didn't
complain.

Why do interfaces allow attributes if they won't be enforced?

Anyone know?

Attributes on an interface member aren't part of the interface
contract, they're modifiers for the member as *part of that
interface*. For example, you might use an attribute to affect whether
CarrierFax is displayed in the IntelliSense list for an ISimpleAddress
variable.

Jesse

 

[Sergiu DUDNIC]

I think, the question was if it's possible to enforce the attributes usage
in a interface.

By example, if I have a have a combobox, with a public Member IdCombo, witch
I wouldn't like to show in the designer,

MyComboBoxSpecial : ComboBox, ICombo
MyComboBoxHome : ComboBox, ICombo
....
MyComboBoxOffice : ComboBox, ICombo


ICombo
{
[DesignTimeVisible(false),
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
long IdCombo { get; set; }
}

I would like to force the usage of these attributes for the property IdCombo
for all My combos... It is possible?

I added a property to an interface like this:
<code>
public interface ISimpleAddress
{
[Bindable(BindableSupport.Yes)]
[EditorBrowsable(EditorBrowsableState.Always)]
string CarrierFax{ get; set; }}

</code>

I was disappointed to see that when I implemented the interface:
1) Visual Studio Refactoring-Auto-Implement tool didn't add the
attributes
2) If I omitted the attributes from the concrete class the compiler
didn't
complain.

Why do interfaces allow attributes if they won't be enforced?

Anyone know?

Attributes on an interface member aren't part of the interface
contract, they're modifiers for the member as *part of that
interface*. For example, you might use an attribute to affect whether
CarrierFax is displayed in the IntelliSense list for an ISimpleAddress
variable.

Jesse

 

[Jesse McGrew]

I think, the question was if it's possible to enforce the attributes usage
in a interface.

By example, if I have a have a combobox, with a public Member IdCombo, witch
I wouldn't like to show in the designer,

MyComboBoxSpecial : ComboBox, ICombo
MyComboBoxHome : ComboBox, ICombo
...
MyComboBoxOffice : ComboBox, ICombo

ICombo
{
[DesignTimeVisible(false),
DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
long IdCombo { get; set; }

}

I would like to force the usage of these attributes for the property IdCombo
for all My combos... It is possible?

No, as far as I know, it's not possible. You have to set the
attributes separately in each class.

Jesse

 

[Steve K.]

I think, the question was if it's possible to enforce the attributes
usage
in a interface.

By example, if I have a have a combobox, with a public Member IdCombo,
witch
I wouldn't like to show in the designer,

MyComboBoxSpecial : ComboBox, ICombo
MyComboBoxHome : ComboBox, ICombo
...
MyComboBoxOffice : ComboBox, ICombo

ICombo
{
[DesignTimeVisible(false),

DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
long IdCombo { get; set; }

}

I would like to force the usage of these attributes for the property
IdCombo
for all My combos... It is possible?

No, as far as I know, it's not possible. You have to set the
attributes separately in each class.

Jesse

Which brings us full circle. ;0)

Do you think an interface that carries these attributes should enforce them?
I'm not one to find shortcomings in c# or complain about the way things
are.... but this seems like it should behave teh way I expected OR... give
me a warning or an error "Property attributes aren't valid for Interface
memebers" - or something.

-Steve

 

[Peter Duniho]

[...]
Do you think an interface that carries these attributes should enforce
them?
I'm not one to find shortcomings in c# or complain about the way things
are.... but this seems like it should behave teh way I expected OR...
give
me a warning or an error "Property attributes aren't valid for Interface
memebers" - or something.

Attributes are arbitrary. They're not part of the language per se IMHO,
but rather something that is defined by a given assembly. Of course, most
of the attributes someone might use are pre-defined by .NET, but you can
make your own by creating a new class that inherits System.Attribute.

To implement a feature like you're asking for would require that the
Attribute class contain some sort of "applicability flags" to indicate
what language elements the attribute makes sense for. It would also
require that every single Attribute-derived class implement those flags
correctly.

Now, I don't see anything that would prevent that from happening. But
personally, I think that it makes more sense for the compiler to stick to
things that it _knows_. There's no way for the compiler to _know_ whether
an attribute applies or not; it can only make an inference based on
information provided to it by some external source. (And yes, I find this
kind of inference to be fundamentally different from other kinds of
inferences compilers _do_ make).

So, in other words, I don't think your request is unreasonable from a
usefulness perspective, but it's not something I think I'd expect to find
in the C# compiler.

Pete

 

[Jeroen Mostert]

Peter Duniho wrote:

To implement a feature like you're asking for would require that the
Attribute class contain some sort of "applicability flags" to indicate
what language elements the attribute makes sense for.

Uh... Ever heard of AttributeUsageAttribute?

And yes, the compiler enforces that.

 

[Steve K.]

[...]
Do you think an interface that carries these attributes should enforce
them?
I'm not one to find shortcomings in c# or complain about the way things
are.... but this seems like it should behave teh way I expected OR...
give
me a warning or an error "Property attributes aren't valid for Interface
memebers" - or something.

Attributes are arbitrary. They're not part of the language per se IMHO,
but rather something that is defined by a given assembly. Of course, most
of the attributes someone might use are pre-defined by .NET, but you can
make your own by creating a new class that inherits System.Attribute.

To implement a feature like you're asking for would require that the
Attribute class contain some sort of "applicability flags" to indicate
what language elements the attribute makes sense for. It would also
require that every single Attribute-derived class implement those flags
correctly.

Making sure I understand what you mean here: For example a "Bindable"
attrbute on a SMTP communication utility class would not make sense? Is
that what you mean?

Now, I don't see anything that would prevent that from happening. But
personally, I think that it makes more sense for the compiler to stick to
things that it _knows_. There's no way for the compiler to _know_ whether
an attribute applies or not; it can only make an inference based on

Again I'm not sure I'm following, it could be that it's over my head. ;0)
Isn't the fact that I've included the attribute on the interface enough to
tell it that it applies? I thought that was the purpose of an interface:
"You must do this and it must support that"

 

[Peter Duniho]

Peter Duniho wrote:


Uh... Ever heard of AttributeUsageAttribute?

No, actually. But how does that help here? There's nothing in there that
I see that would allow an attribute to be qualified according to the
container something's found in. If it's a valid attribute for a method,
it's valid wherever the method is declared.

And yes, the compiler enforces that.

If AttributeUsageAttribute was relevant here, then the OP would have a
valid complaint about the specific attributes being used (but not the
compiler). But I don't see the relevance. How does
AttributeUsageAttribute help with respect to indicating whether an
attribute is applicable only to a method implementation versus a method
declaration in an interface?

Pete

 

[Jeroen Mostert]

No, actually. But how does that help here?

It doesn't. I'm just pointing out that your assertion is wrong (or at best
misleading). I'm not trying to help the OP (whose exact problem is indeed
unsolvable).

How does AttributeUsageAttribute help with respect to indicating whether
an attribute is applicable only to a method implementation versus a
method declaration in an interface?

There's no reason for the language to implement that, and it's not what the
OP is asking for. The OP ultimately wants an attribute declared on an
interface method to be applied (without a way to override) to an
implementation of that method in a class.

Unfortunately, attributes do not work that way. The best you get is that by
default, attributes are inherited, so at least inherited members will have
the attributes of the base method. However, this does not prevent the
overriding member from redefining this attribute.

The OP's problem would be solved if implementing an interface member counted
as inheritance, but it does not. An abstract base class works, though.

 

[Peter Duniho]

Making sure I understand what you mean here: For example a "Bindable"
attrbute on a SMTP communication utility class would not make sense? Is
that what you mean?

I don't understand the question. I don't know enough about binding to
know what it would mean to bind a whole class, but assuming you had
something about your utility class that was in fact bindable, why not have
the property on the class?

The point would be that the class author should not apply the
BindableAttribute attribute to the class if the class shouldn't be used in
binding. If you're asking about someone _using_ the class applying that
attribute to a property or variable referencing an instance of the class,
then whether the BindableAttribute attribute makes sense would, I think,
depend on whether you had a reliable way to connect the property or
variable to something that gets or sets an instance of the class.

What about the BindableAttribute attribute is it that you're saying is
inherently incompatible with this "SMTP communication utility class"? And
more important, why is that relevant to what I wrote?

Again I'm not sure I'm following, it could be that it's over my head. ;0)
Isn't the fact that I've included the attribute on the interface enough
to
tell it that it applies? I thought that was the purpose of an interface:
"You must do this and it must support that"

I think you're looking at it from the wrong end. The attribute applies to
the member of the _interface_, as Jesse wrote. You're expecting it to
somehow propagate from the interface to something that implements the
interface, but they don't. The attribute you write in the interface
applies _to the member of the interface_ itself.

Interfaces are themselves legitimate language objects. They aren't just
syntax. They are a "thing" just like a class, struct, enum, etc. is a
thing. And when you apply an attribute, it applies to the thing, not the
thing that uses the thing.

Now, for some members it may be that in an interface the attribute doesn't
make any sense or isn't useful. But there's no way to represent that as
far as I know.

In any case, you asked a specific question, which essentially was "should
I be surprised at how this works?" I answered that with essentially a
"no". I understand why you were surprised, but I don't find the behavior
itself surprising, nor do I think it should be surprising once you think
about what the attribute is actually applied to. But keep in mind that
that's just my opinion. The behavior doesn't surprise me and so I don't
think it should surprise you. But that's just my opinion, which you asked
for. If you want to be surprised, I think that's your prerogative.

Pete

 

[Peter Duniho]

It doesn't. I'm just pointing out that your assertion is wrong (or at
best misleading). I'm not trying to help the OP (whose exact problem is
indeed unsolvable).

It's not unsolvable. It's just not supported, and my opinion is that it's
not surprising it's not supported.

There's no reason for the language to implement that, and it's not what
the OP is asking for.

It is what the OP is asking for. The attributes in the interface
declaration are applying to the members of the interface itself. He
really wants them to be inherited by implementors of the interface, but
_his question_ pertained to why he's permitted to apply attributes that
ultimately have no effect.

In other words, the impliciation is that he would satisfied if attributes
had some way of representing that they were invalid in the context of
being applied to something declared within an interface, so that he would
at least get a compile-time error (or warning) alerting him to the fact
that the attributes are doing nothing.

The OP ultimately wants an attribute declared on an interface method to
be applied (without a way to override) to an implementation of that
method in a class.

Of course that's what he _ultimately_ wants. But that's not what he was
asking about at the point that I replied.

Pete

 

[Steve K.]

Interfaces are themselves legitimate language objects. They aren't just

syntax. They are a "thing" just like a class, struct, enum, etc. is a
thing. And when you apply an attribute, it applies to the thing, not the
thing that uses the thing.

This cleared it up right here. I was thinking of an interface as a
"template" not an actual object. I saw it this way because you can't
instantiate an interface or have any implementation at all so my brain,
small and overworked as it is was looking at them as templates. I
understand now that the attributes are applied to the interface. Got it.

Thanks for the help,
Steve