Alternative Ways To Implement "Events"

[Smithers]

Just looking to compile a list of "all the ways to implement events".

I'm NOT looking to get into the merits or mechanics of each in this
thread... just want to identify them all - good, bad, and ugly.

Here's what I have so far
1. Implement via the 'event' keyword (with associated delegate, etc)

2. Expose a private delegate via a public property (really a "roll yer own"
version of the 'event' keyword method).

3. Old-school callbacks in which one object (objA) calls another (objB),
passing a reference of itself to the called object (objB then contains a
reference to objA). The called object can then call methods on the calling
object (i.e., objB calls methods of objA).

4 ... ???

I'd appreciate any additional ways to implement "events" - including total
hacks.

I'm looking to grasp finally grasp the entire landscape of events and
callback mechanisms that are available in .NET (even if they are independent
of .NET, like plain ole' callbacks).

Thanks.

 

[Nicholas Paldino [.NET/C# MVP]]

Smithers,

Technically, you have to use the "event" keyword when you want to have
an event on your type. This is baked into the metadata (and shown through
Reflection) as an event. All the methods, besides #1, are not events,
technically.

 

[Samuel R. Neff]

In some places .NET uses attributes to subscribe event handlers. Look
at OnSerializingAttribute and related attributes (there's 4 of them).

Java (at least as of 1.4, not sure if it changed), implements events
using interfaces. Instead of declaring an event like in C# each event
type has an interface and there are methods for subsribing to an
"event" by providing an interface implementation. Then inner classes,
especially anonymous inner classes, are heavily used as "event"
handlers. I probably have some details wrong but I'm pretty sure on
the basic principle.

DOM (JavaScript, ActionScript) implements events using name events and
function references (delegates). I've actually seen people implement
custom events in .NET this way, but in that situation we turned down
the contract because of that odd requirement.


And to be perfectly clear, I'm not advocating or condoning the use of
any of these methods over the standard way to create events in .NET..
just you asked for everything.

HTH,

Sam

 

[Nicholas Paldino [.NET/C# MVP]]

Samuel,

The OnSerializingAttribute does not subscribe the method to an event.
While loosely, it is an event, the serialization engine uses reflection to
call the method.

 

[Smithers]

<snip>

<< While loosely, it is an event, the serialization engine uses reflection
to call the method >>>

<snip>

Nicholas,

Please note that the answer that Samuel provided is *exactly* the sort of
response I was looking for in my OP.

Please note that the OP subject has the word, events, in quotes ("events")
which indicates that I'm looking not only for events, but also anything that
can be roughly construed as an event. I went on in the body of the OP to
continue the use of quotes, and even explicitly requiested "total hacks"
(meaning not prim and proper events).

Please do not discourage folks from responding simply because they aren't
providing some way to implement events according to some narrow technically
specific definition. If thats' what I wanted, the OP wouldn't have described
my intent as going after the "entire landscape" of events and callback
mechanisms.... even those that are independent of .NET."

-S

 

[Nicholas Paldino [.NET/C# MVP]]

I'm not trying to discourage people from answering, but I don't want to
spread the wrong impression about what an event is in .NET. It has a very
concrete definition (reflected by the metadata reflected on the type, and
reflected through the EventInfo type in the System.Reflection namespace).

To be frank, the question that you asked has a vast number of answers.
You are basically looking for anything that can signal your code in response
to an action. The number of mechanisms for this is pretty huge.

Some are more common than others, granted, and I feel you have hit on
all of the common ones, I believe, but there are many more to be had
(depending on the scenario and context).

 

[Smithers]

Exactly. It is precisely because there are so many possible answers
(including hacks) that I came to the group for ideas. I don't pretend to
know them all, and I'm wanting to better understand this
publish-and-subscribe landscape.

I do understand your point of wanting to prevent others from becoming
misguided on what constitutes an event. Perhaps I should have omitted the
word "event" - though I thought it was pretty clear on that in the OP by
stating that I was looking for ideas including hacks and non .NET-specific
mechanisms.

Hopefully others will still pitch in for more of these non event ways to
signal code in response to an action.

-S

 

[Samuel R. Neff]

And since I guess you missed this part of my original post, I'll
repeat..

"
And to be perfectly clear, I'm not advocating or condoning the use of
any of these methods over the standard way to create events in .NET..
just you asked for everything.
"

While this may seem like a silly question, silly questions come up a
lot (especially in consulting contracts, which I'm glad we no longer
have to deal with) and it's always good to be knowledgeable about the
subject and know lots of ways to do things, even if you'd never
actually use them 'cause there is an accepted best practice (and of
course best practices do change over time, for example events are
different in plain .NET and WPF--although WPF events are based and a
wrapper of .NET events).

btw, Smithers, that's another one to add to your list. WPF supports
tunneling and bubbling of events. I'm not the most qualified to
explain it, but it's a very nice extension to .NET events.

Sam

 

[Smithers]

Thank you Samuel,

Yes, it is a silly question. But I'm asked silly questions all the time by
clients and junior programmers. I am currently doing a bit on events and
delegates (more to it, admittedly, that anticipated when I started this
effort). I am going to add a section for "how to NOT do events" that
includes some popular or somehow intuitive-yet-BAD ways to do them (them
being "events" and event-like mechanisms, callbacks, and any other
publish/subscribe mechanism by which objects can communicate). Other authors
take the same tact. There is a book titled "Database Design for Mere
Mortals" that includes a chapter titled, "Bad Design - What Not To Do."
Including that chapter gives new DBAs more of a frame of reference for the
right ways to do things.

BTW: thanks for the addition of bubbling and/or tunneling of events in WPF.
Gives me additional things to look for. Perhaps they are simply new
descriptive terms to describe things we already have - or maybe they are
entirely new implementations of events or subscription/notification or
callback mechanisms. In any case I'll check them out... to be added to
either the "mainstream accepted/supported" list or the "don't do this" list
with an explanation of why we shouldn't do things that way.

For those who may be interested in answers relevant to the OP, I've since
come up with "loosely coupled events" as supported by
System.EnterpriseServices (described by Juval Lowy in his books titled
"Programming .NET Components", and "COM and .NET ComponentServices")

-"Smithers"