Event method accessibility

[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.

[Daniel O'Connell]

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.
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:eO****************@TK2MSFTNGP11.phx.gbl...

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.

[Edward Diener]

Daniel O'Connell wrote:

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.
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" <ed******@tropicsoft.com> wrote in message
news:eO****************@TK2MSFTNGP11.phx.gbl...

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.

[Daniel O'Connell]

"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Daniel O'Connell wrote:

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.
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.
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. 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.

"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:eO****************@TK2MSFTNGP11.phx.gbl...

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.