Event method accessibility

  • Thread starter Thread starter Edward Diener
  • Start date Start date
E

Edward Diener

According to the CLS specification, the accessibility of the methods for
adding, removing, and raising an event must be identical. There appear to be
a few problems with this:

1) According to the Managed C++ specifications, if one declares a public
event without any attempt to provide one's own event access methods, clearly
the most common case, the compiler generates public add_ and remove_ methods
for the event and a protected raise_ method for the event. This appears to
contradict CLS guideleines for the event and make events declared in MC++
non-compliant with the CLS specification.

2) If I provide my own event member methods signature for the event, I might
want to allow any code to add or remove event handlers for the event, the
common case, while restricting the ability to raise the event to classes in
my own assembly. I can do this by specifying that the accessibility for the
event add_ and remove_ remove methods be made public while the accessibility
for the raise_ method is made public private. If I do this, once again I am
not complying to the CLS specification.

Clearly not complying to the CLS specification will not allow my class to be
used by other .NET languages, which is something which I don't want. However
being able to control which classes are allowed to raise a particular
class's event seems to be a common idiom in computer programming. I know
that .NET makes a big deal about only the class which contains the event
being able to raise the event, but it is clear that designs may call for
other classes being able to raise the event also. This may not have been a
big deal for C++ programmers if the 'friend' functionality were allowed in
the MC++ specification, but it is not. Luckily the concept of assembly
classes having access priveleges which classes outside the assembly do not
have, was added to MC++ specification. However, the CLS guidelines for event
methods having equal accessibility makes it impossible to vary the
accessibility of event methods. Hopefully someone understands this issue and
knows of a way out of this conundrum.
 
Further down in the CIL standard, raise_XXX pattern is defined as:
Pattern: void family raise_<EventName> (Event e)
family is what protected in C++ & C# is, just the cil name. I *think*,
although I can't find a definitive source, that the raise_ method is not an
accessor per se, whereas add and remove are. It isn't very clearly written.
 
Daniel said:
Further down in the CIL standard, raise_XXX pattern is defined as:
Pattern: void family raise_<EventName> (Event e)
family is what protected in C++ & C# is, just the cil name. I *think*,
although I can't find a definitive source, that the raise_ method is
not an accessor per se, whereas add and remove are. It isn't very
clearly written.
Click to expand...

No, it isn't. Especially when it does clearly state in the CLS specification
topic on MSDN that the accessor accessibility for "adding, removing, and
raising an event must be identical." Could this be wrong, and it is only the
"adding and removing" which must have identical accessibility ? Because if
it is correct, every MC++ program which uses the normal "__event
SomeDelegate * eventName;" or "__event returnType
eventName(eventParameters);" is CLS non-compliant, since it generates the
add and remove methods as public and the raise method as protected.

Perhaps MS has clarified this somewhere, but I could not find anything
further on it on their web site. It is scary to think that, according to the
MSDN doc, all MC++ modules which use events are non-compliant with the CLS
and therefore can not be used interchangeably with other .NET languages. I
am sure this can not be the case but the CLS compliant documentation is
clearly saying that it is.
 
Edward Diener said:
No, it isn't. Especially when it does clearly state in the CLS specification
topic on MSDN that the accessor accessibility for "adding, removing, and
raising an event must be identical." Could this be wrong, and it is only the
"adding and removing" which must have identical accessibility ? Because if
it is correct, every MC++ program which uses the normal "__event
SomeDelegate * eventName;" or "__event returnType
eventName(eventParameters);" is CLS non-compliant, since it generates the
add and remove methods as public and the raise method as protected.
Click to expand...
I couldn't find this information, I used the ECMA spec, do you have a
reference? In languages like C#, the raise_ method doesn't appear to be
there most of the time(at all?), that and the ECMA spec showing a family
modifer suggests to me that there is a problem with the MSDN documentation.
Perhaps MS has clarified this somewhere, but I could not find anything
further on it on their web site. It is scary to think that, according to the
MSDN doc, all MC++ modules which use events are non-compliant with the CLS
and therefore can not be used interchangeably with other .NET languages. I
am sure this can not be the case but the CLS compliant documentation is
clearly saying that it is.
Click to expand...
I wouldn't worry about it much. I prefer to use protected raiser
methods(like OnMyEvent) instead of allowing inheriters to directly access
the event. So I find this to probably not be of much issue if you follow a
similar pattern. In the framework, most events are fired by the base OnXXX
method, which is why you should almost always call the base implementation.
 
Back
Top