Events vs. Delegates

"Burkhard" <Bu******@discussions.microsoft.com> wrote in message
news:DF**********************************@microsof t.com...

Hi,

I am new to C# (with long year experience in C++) and I am a bit confused
by
the language construct of events. What is it I can do with events that I
cannot do with delegates? At the moment it seems to me that Microsoft has
developed similar functionality via two keywords. I do understand that an
event offers better encapsulation as the underlying delegate is private,
but
is that all ?

Well, the encapsulation is really the important part. Allowing outside
clients the ability to clear or execute events is just not acceptable.

However, event and delegate, while they look the same, work differently.
Event's are basically a type of property that offers a standard set of
accessors to the outside world, add, remove, and optionally raise(although
the spec allows for arbitrary accessors.) They also stand out in metadata as
events and not just as a field of type delegate which does have some
semantic value. An event is something you can subscribe to freely, whereas a
delegate doesn't offer that type of definition. Delegate fields can and are
used for other purposes fairly often.

Put simply, an event is an event, whereas a delegate only might be.

Mar 12 '06 #2

Peter Rilling

Events are field (well, not always, but mostly), Delegates are classes.
Event are just "containers" for one or more delegates. When an event
happens, all the delegates registered for a particular event are called. A
delegate is a function pointer which points to the "callback" function used
to handle the event.

They are completely different and have no similar functionality, but they
are used together so that the raising of an event calls one of your methods.

Delegates are never private (never say never). They will most always be
public because your code needs to be able to create an instance of them.

Things are a little bit more complicated than what I have said, but this
should give you an idea that they are different. Events and delegates are
no more similar than an enum and a property.

"Burkhard" <Bu******@discussions.microsoft.com> wrote in message
news:DF**********************************@microsof t.com...

Hi,

I am new to C# (with long year experience in C++) and I am a bit confused
by
the language construct of events. What is it I can do with events that I
cannot do with delegates? At the moment it seems to me that Microsoft has
developed similar functionality via two keywords. I do understand that an
event offers better encapsulation as the underlying delegate is private,
but
is that all ?
--
Regards
Burkhard

Mar 12 '06 #3

Mike

http://blog.monstuff.com/archives/000040.html

"Burkhard" <Bu******@discussions.microsoft.com> wrote in message
news:DF**********************************@microsof t.com...

Hi,

I am new to C# (with long year experience in C++) and I am a bit confused
by
the language construct of events. What is it I can do with events that I
cannot do with delegates? At the moment it seems to me that Microsoft has
developed similar functionality via two keywords. I do understand that an
event offers better encapsulation as the underlying delegate is private,
but
is that all ?
--
Regards
Burkhard

Mar 12 '06 #4

Burkhard <Bu******@discussions.microsoft.com> wrote:

I am new to C# (with long year experience in C++) and I am a bit confused by
the language construct of events. What is it I can do with events that I
cannot do with delegates? At the moment it seems to me that Microsoft has
developed similar functionality via two keywords. I do understand that an
event offers better encapsulation as the underlying delegate is private, but
is that all ?

Think of it like fields and properties, except that for events in C#
there happens to be a shorthand way of writing the common code.

You need a field (or *something*) to store the delegate references to
call, but the event itself is just a pair of methods (for subscribing
and unsubscribing) just as the property itself is just a pair of
methods for getting/setting the value. It's easier to understand this
when you see what a "field-like event" declaration is compiled to.

public event EventHandler Foo;

is compiled to two parts. One is a field:

private EventHandler FooField;

and one is the event itself:

public event EventHandler Foo
{
add
{
lock (this)
{
FooField += value;
}
}
remove
{
lock (this)
{
FooField -= value;
}
}
}

Now, a few notes:

1) FooField is *actually* a field with name Foo. I've just called it
FooField here for clarity. The C# compiler wouldn't actually let you
explicitly declare a field with the same name as the event.

2) The "lock(this)" is true with C# 1.1, but may not be true in 2.0 -
it's up to the compiler to decide what to lock on in 2.0. To my mind,
neither of these are really great. See
http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 12 '06 #5

Peter Bromberg [C# MVP]

Actually,

the event keyword is used to create a delegate - an event delegate -- you
just don't use the "new" keyword.

So for example the line:

public event MouseEventHandler handler;

would create an instance of a MouseEventhandler delegate whose signature
might look like this:

public delegate void MouseEventHandler(object source, MouseEventArgs args);

The event keyword tells the compiler that this delegate instance is an event.

Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

"Burkhard" wrote:

Hi,

I am new to C# (with long year experience in C++) and I am a bit confused by
the language construct of events. What is it I can do with events that I
cannot do with delegates? At the moment it seems to me that Microsoft has
developed similar functionality via two keywords. I do understand that an
event offers better encapsulation as the underlying delegate is private, but
is that all ?
--
Regards
Burkhard

Mar 12 '06 #6

Peter Bromberg [C# MVP] <pb*******@yahoo.nospammin.com> wrote:

the event keyword is used to create a delegate - an event delegate -- you
just don't use the "new" keyword.

So for example the line:

public event MouseEventHandler handler;

would create an instance of a MouseEventhandler delegate whose signature
might look like this:

No, that doesn't create any instances of the MouseEventHandler
delegate. It creates an instance field of type MouseEventHandler, along
with an event of the same name and type. No instances are created,
however - the default value is null (just as for other reference type
variables).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 12 '06 #7

Mike

Personally, "event" seems like a wart and a lot of hacky sugar for very
little gain, and some restrictions that may be limiting.

I think just plain delegates, and an [Event...] attribute for delegate
fields for tools that like to distingish events would have done just as
well.

Certainly, there's not much difference bettween typing these two lines (or
more likely, having the IDE do it for you):

[Event] public DelegateType Field;
public event DelegateType Field;

That's what attributes are made for.

As for the Interface contract, the framework need just define:
interface IEventSource { Add(...); Remove(...); ... }
and:
class EventSource : IEventSource { /* handle add/remove */ /* overload
+ */ /* etc...*/ }

and replace:

interface IFoo { event DelegateType TheEvent; event DelegateType2
TheEvent2;...
with
interface IFoo { EventSource TheEvent {get;} ; EventSource TheEvent2
{get;} ; ...

and Bob's your uncle...

This needs no extra language features (like an "event" keyword), has no more
"source bulk", and is much more explict. (With the "event" keyword you just
have to "know" there's a property-like field created - here it's explicit,
and the add/remove code is implemented in a proper object (which you can
provide if you like), and not in a hacked (and hidden, unless you know to
override) "add"/"removed" sections of the generated event code.)
You could also use generics if you wanted to keep the typing of the
delegate, but this isn't necessary seeing with an "event" handler your are
typically forced to using (EventSource, EventArgs) anyway. Still, it would
probably be nice to allow:

interface IFoo { TEventSource<DelegateType> TheEvent {get;} ;
TEventSource <DelegateType2> TheEvent2 {get;} ; ...

where the normal EventSource is already "specialized" on a (Sender,
EventArgs) delegate.

m
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Peter Bromberg [C# MVP] <pb*******@yahoo.nospammin.com> wrote:
the event keyword is used to create a delegate - an event delegate -- you
just don't use the "new" keyword.

So for example the line:

public event MouseEventHandler handler;

would create an instance of a MouseEventhandler delegate whose signature
might look like this:

No, that doesn't create any instances of the MouseEventHandler
delegate. It creates an instance field of type MouseEventHandler, along
with an event of the same name and type. No instances are created,
however - the default value is null (just as for other reference type
variables).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 12 '06 #8

"Mike" <vi********@yahoo.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

Personally, "event" seems like a wart and a lot of hacky sugar for very
little gain, and some restrictions that may be limiting.

I think just plain delegates, and an [Event...] attribute for delegate
fields for tools that like to distingish events would have done just as
well.

Certainly, there's not much difference bettween typing these two lines (or
more likely, having the IDE do it for you):

[Event] public DelegateType Field;
public event DelegateType Field;

That's what attributes are made for.

As for the Interface contract, the framework need just define:
interface IEventSource { Add(...); Remove(...); ... }
and:
class EventSource : IEventSource { /* handle add/remove */ /* overload
+ */ /* etc...*/ }

and replace:

interface IFoo { event DelegateType TheEvent; event DelegateType2
TheEvent2;...
with
interface IFoo { EventSource TheEvent {get;} ; EventSource TheEvent2
{get;} ; ...

and Bob's your uncle...

This needs no extra language features (like an "event" keyword), has no
more "source bulk", and is much more explict. (With the "event" keyword
you just have to "know" there's a property-like field created - here it's
explicit, and the add/remove code is implemented in a proper object (which
you can provide if you like), and not in a hacked (and hidden, unless you
know to override) "add"/"removed" sections of the generated event code.)
You could also use generics if you wanted to keep the typing of the
delegate, but this isn't necessary seeing with an "event" handler your are
typically forced to using (EventSource, EventArgs) anyway. Still, it would
probably be nice to allow:

Isn't that alot of extra code(and extra logic for compilers and code
analysers) for virtually no benefit? The CLR itself defines events, there is
metadata, an extensible set of accessors, and explicit rules tied to them,
they are as first class as methods, properties, and fields within the
runtime. If you read up on the language, runtime, or anything else it will
become clear.

Beyond that, your solution is not more explicit, it hides things behind a
class most users won't realize you can dig into(or forces them to write more
classes , which to my mind *IS* code bloat,) forces the end user to write
properties(which the current mechanism doesn't) and it uses an attribute,
which, IMHO, is the #1 wrong thing to do with any first class language
feature. Attributes should apply only metadata, and with very few
exceptions, not change the meaning of a line of code. By using an attribute
to define semantics you complicate the use of the language, if not the
language itself, with artificial markers. I think the current method is far
better than the one you suggest here.

Mar 12 '06 #9

Mike <vi********@yahoo.com> wrote:

Personally, "event" seems like a wart and a lot of hacky sugar for very
little gain, and some restrictions that may be limiting.

I think just plain delegates, and an [Event...] attribute for delegate
fields for tools that like to distingish events would have done just as
well.

Certainly, there's not much difference bettween typing these two lines (or
more likely, having the IDE do it for you):

[Event] public DelegateType Field;
public event DelegateType Field;

There's a *very* big different. With the first, *anyone* can change the
field, to anything - no restrictions. With the second, you've only got
subscribe/unsubscribe. They encapsulate different things.

<snip>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 12 '06 #10

Mike

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uu**************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

Personally, "event" seems like a wart and a lot of hacky sugar for very
little gain, and some restrictions that may be limiting.

I think just plain delegates, and an [Event...] attribute for delegate
fields for tools that like to distingish events would have done just as
well.

Certainly, there's not much difference bettween typing these two lines
(or more likely, having the IDE do it for you):

[Event] public DelegateType Field;
public event DelegateType Field;

That's what attributes are made for.

As for the Interface contract, the framework need just define:
interface IEventSource { Add(...); Remove(...); ... }
and:
class EventSource : IEventSource { /* handle add/remove */ /*
overload + */ /* etc...*/ }

and replace:

interface IFoo { event DelegateType TheEvent; event DelegateType2
TheEvent2;...
with
interface IFoo { EventSource TheEvent {get;} ; EventSource TheEvent2
{get;} ; ...

and Bob's your uncle...

This needs no extra language features (like an "event" keyword), has no
more "source bulk", and is much more explict. (With the "event" keyword
you just have to "know" there's a property-like field created - here it's
explicit, and the add/remove code is implemented in a proper object
(which you can provide if you like), and not in a hacked (and hidden,
unless you know to override) "add"/"removed" sections of the generated
event code.)
You could also use generics if you wanted to keep the typing of the
delegate, but this isn't necessary seeing with an "event" handler your
are typically forced to using (EventSource, EventArgs) anyway. Still, it
would probably be nice to allow:

Isn't that alot of extra code(and extra logic for compilers and code
analysers) for virtually no benefit?

Obviously, I don't think so :)
(A) It's not extra code (the # of chars is pretty close (8 more chars?), as
above)
(B) Most of this boilerplate code is generated for you anyway
The CLR itself defines events, there is metadata
The metadata can exist in either scheme, as with [Event...] above.
, an extensible set of accessors, and explicit rules tied to them,
Exactly - those rules need not be there.
they are as first class as methods, properties, and fields within the
runtime. If you read up on the language, runtime, or anything else it will
become clear.
I understand your viewpoint - but your reply to me seems to be:
"your idea that events should not be first-class is wrong, because they are"
doesn't seem to go anywhere.
Beyond that, your solution is not more explicit,
Huh? *Nothing* is hidden. All class and interfaces are mentioned explicitly.
This is in contrast to the event where an event declaration goes ahead and
creates lots of crap behind the scenes,
including a property-like definition with add/remove sections that could
easily be normal method invocations.
it hides things behind a class most users won't realize you can dig into
Well, there's no reason for most users to "dig into" it at all - it just
works, and appears from the client's perspective just like the current
events, with += and the like. If advanced users want to add functionality to
an event (let's say "ClearAll()" or "SetInvokeThreadingMode(...)" or
"SetInvokeExceptionChainMode(...) or whatever) they now have a class to
extend or replace - where with the currnent model add{} and remove{} are set
in stone. (At least from the c#-side, maybe not from the CLR's perspective.)
forces them to write more classes
Not that I can see - the event classes/interfaces would all be in the
framework.
forces the end user to write propertis(which the current mechanism
doesn't)
People define properties at the drop of a hat, mostly when not necessary -
why then allow public access to your event field? it uses an attribute, which, IMHO, is the #1 wrong thing to do with any
first class language feature.
True - but again, not a problem if they aren't first-class...
Attributes should apply only metadata, and with very few exceptions, not
change the meaning of a line of code.
It does not change the meaning of the code -- the Event metadata is only for
tools that wish to use it. (Intellisense, etc.)
By using an attribute to define semantics you complicate the use of the
language, if not the language itself, with artificial markers. I think the
current method is far better than the one you suggest here.

Again, I don't see where I led you to beleive the attribute had any effect
on semantics or generated code at all.
The whole point of my post is that we can get by with existing (excluding
the event keyword) language features only, and end up with a much more
general system.

I'm not ready to ship my my ten-minute design by any means - I'm just saying
I think we'd all live without the "event" keyword.
I'm not saying it's horrible - I think c# is great. It's just weather you
think a certain feature is above or below the line of being necessary - and
I think people are split on this particular one. Although I stay away from
GUI's as much as possible, I can see that if you were programming GUI's all
the time and did not have good tool support, that you'd want to minimize
what is necessary to get basic events working.

m

Mar 12 '06 #11

Mike

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike <vi********@yahoo.com> wrote:
Personally, "event" seems like a wart and a lot of hacky sugar for very
little gain, and some restrictions that may be limiting.

I think just plain delegates, and an [Event...] attribute for delegate
fields for tools that like to distingish events would have done just as
well.

Certainly, there's not much difference bettween typing these two lines
(or
more likely, having the IDE do it for you):

[Event] public DelegateType Field;
public event DelegateType Field;
There's a *very* big different. With the first, *anyone* can change the
field, to anything - no restrictions. With the second, you've only got
subscribe/unsubscribe. They encapsulate different things.

Yes - I provided a mixed model that isn't exactly what I had in mind - I
supposed I shouldn't have posted if I wasn't will to put up a design that
reflected my thinking - I suppose in my copious spare time, I'll try and do
so. In this case the delegate should be black-boxed by a class (framework
provided, if desired) that exposes only subscribe/unsubscribe, if that is
desired, and the attribute belongs on the field/property that returns the
EventSource, not on the delegate field itself, unless simple, unrestricted
access is permitted. (I conflated some of the event provider and client code
in my post.)

m

<snip>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 13 '06 #12

"Mike" <vi********@yahoo.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uu**************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

Personally, "event" seems like a wart and a lot of hacky sugar for very
little gain, and some restrictions that may be limiting.

I think just plain delegates, and an [Event...] attribute for delegate
fields for tools that like to distingish events would have done just as
well.

Certainly, there's not much difference bettween typing these two lines
(or more likely, having the IDE do it for you):

[Event] public DelegateType Field;
public event DelegateType Field;

That's what attributes are made for.

As for the Interface contract, the framework need just define:
interface IEventSource { Add(...); Remove(...); ... }
and:
class EventSource : IEventSource { /* handle add/remove */ /*
overload + */ /* etc...*/ }

and replace:

interface IFoo { event DelegateType TheEvent; event DelegateType2
TheEvent2;...
with
interface IFoo { EventSource TheEvent {get;} ; EventSource TheEvent2
{get;} ; ...

and Bob's your uncle...

This needs no extra language features (like an "event" keyword), has no
more "source bulk", and is much more explict. (With the "event" keyword
you just have to "know" there's a property-like field created - here
it's explicit, and the add/remove code is implemented in a proper object
(which you can provide if you like), and not in a hacked (and hidden,
unless you know to override) "add"/"removed" sections of the generated
event code.)
You could also use generics if you wanted to keep the typing of the
delegate, but this isn't necessary seeing with an "event" handler your
are typically forced to using (EventSource, EventArgs) anyway. Still, it
would probably be nice to allow:

Isn't that alot of extra code(and extra logic for compilers and code
analysers) for virtually no benefit?

Obviously, I don't think so :)
(A) It's not extra code (the # of chars is pretty close (8 more chars?),
as above)
(B) Most of this boilerplate code is generated for you anyway

It still requires overriding a concrete class or implementing an interface
to change add/remove behavior.

The CLR itself defines events, there is metadata
The metadata can exist in either scheme, as with [Event...] above.

Certainly it could, but why? For something that is probably more common than
a great many other features(like stackalloc or static classes, for example,)
this lacks any reason. Do you *HAVE* a reason that this is better? Or do you
just think it is because its teh way you expected it to be?

, an extensible set of accessors, and explicit rules tied to them,
Exactly - those rules need not be there.

They'd clearly have to exist, they'd just be different. Instead of event
metadata, you'd have a rule about the type of event container you'd have to
use or what have you. it's still there.

they are as first class as methods, properties, and fields within the
runtime. If you read up on the language, runtime, or anything else it
will become clear.
I understand your viewpoint - but your reply to me seems to be:
"your idea that events should not be first-class is wrong, because they
are" doesn't seem to go anywhere.

You're suggestion here has basically been "its wrong because I say so."
You've offered nothing as far as evidence or reasoning, except that you
weren't aware of something that you really don't need to be aware of. Events
deserve to be first class features, they offer semantic value and are quite
commonly used, IMHO.

Beyond that, your solution is not more explicit,
Huh? *Nothing* is hidden. All class and interfaces are mentioned
explicitly.
This is in contrast to the event where an event declaration goes ahead and
creates lots of crap behind the scenes,
including a property-like definition with add/remove sections that could
easily be normal method invocations.

That is sugar to save you time. Its not like the langauge designers are
going out of hteir way to make sure you don't know about the add/remove
accessors.

it hides things behind a class most users won't realize you can dig into

Well, there's no reason for most users to "dig into" it at all - it just
works, and appears from the client's perspective just like the current
events, with += and the like. If advanced users want to add functionality
to an event (let's say "ClearAll()" or "SetInvokeThreadingMode(...)" or
"SetInvokeExceptionChainMode(...) or whatever) they now have a class to
extend or replace - where with the currnent model add{} and remove{} are
set in stone. (At least from the c#-side, maybe not from the CLR's
perspective.)

This is pretty irrelevent. Is your argument really "it works the same, so
why not?" All of your suggestions basically are going to make things harder
on everyone. The current model has none of htese features because they
aren't needed. There is no concept of threading mode or invocation mode. All
of that is pretty advanced I'll give you, but it is alot of complicated
machinary for very little benefit, IMHO. Anything that requires that
complicated of an invocation model probably shouldn't be using events as
they stand(a COM\Java like event sink mechanism would be my recommendation.)
forces them to write more classes
Not that I can see - the event classes/interfaces would all be in the
framework.

Unless they want to change the way it stores or validates anything, that is.
If it want's to handle add, remove, or anything else you've got to derive a
class(probably an inner class as well, since you might want access to the
local fields).
forces the end user to write propertis(which the current mechanism
doesn't)
People define properties at the drop of a hat, mostly when not necessary -
why then allow public access to your event field?

Come again? I don't get what you are implying here.

it uses an attribute, which, IMHO, is the #1 wrong thing to do with any
first class language feature.

True - but again, not a problem if they aren't first-class...

Yet you've yet to come up with any reason why it shouldn't be.
Attributes should apply only metadata, and with very few exceptions, not
change the meaning of a line of code.

It does not change the meaning of the code -- the Event metadata is only
for tools that wish to use it. (Intellisense, etc.)

It does change the meaning. An event is a far different thing than a
property. It is conceptually a notification sink and is treated as such *IN
CODE*. Thus the attribute changes the meaning of the property and any code
that uses it and, therefore, defines semantics.

By using an attribute to define semantics you complicate the use of the
language, if not the language itself, with artificial markers. I think
the current method is far better than the one you suggest here.
Again, I don't see where I led you to beleive the attribute had any effect
on semantics or generated code at all.
The whole point of my post is that we can get by with existing (excluding
the event keyword) language features only, and end up with a much more
general system.

You can get by with quite a few more general features alone. You can throw
away properties and define a Property<T> type that has optional get & set
methods. You could do away with iterators, return values, operators,
delegates, and a whole host of other things as well. The point of it all
isn't that you *CAN* get rid of it, the point is that it is easier and\or
permits new scenarios with no costs on any level.

I'm not ready to ship my my ten-minute design by any means - I'm just
saying I think we'd all live without the "event" keyword.
I'm not saying it's horrible - I think c# is great. It's just weather you
think a certain feature is above or below the line of being necessary -
and I think people are split on this particular one. Although I stay away
from GUI's as much as possible, I can see that if you were programming
GUI's all the time and did not have good tool support, that you'd want to
minimize what is necessary to get basic events working.

People are split? You are the first person I've ever seen suggest events
don't need to be there. They are incredibly simple, distinction from
delegate and events excluded, I really don't get your problem with them. You
seem just to think they are a bad idea.

Mar 13 '06 #13

William Stacey [MVP]

I see what your saying and have wondered on that from time to time. But with the event modifier you get this for ~free:
1) You can't invoke a event from outside the class that contains the event delegate.
2) You can include an event in a interface. In contrast, you could not add a plain delegate (or class) to an interface as you can't add fields to an interface.
3) You can't assign an Event to a "plain" delegate var and run it to get around the invoke restrictions.
4) You can't make an assignment to an Event from outside the containing class (i.e. external readonly).
5) You don't "see" properties on the type that you can't call. Actually, you don't "see" any members on events from intellisense.

Those would be hard or impossible to do by containing a delegate in a Event class. Below Event class is an example:
public sealed class Event

{

private EventHandler del;

public Event()

{

}

public int Count

{

get

{

EventHandler temp = del;

if ( temp == null )

return 0;

return temp.GetInvocationList().Length;

}

}

public void Add(EventHandler del)

{

this.del += del;

}

public void Remove(EventHandler del)

{

this.del -= del;

}

public void RemoveAll()

{

this.del = null;

}

public static Event operator +(Event e, EventHandler eventHandler)

{

if (e == null)

return null;

e.Add(eventHandler);

return e;

}

public static Event operator -(Event e, EventHandler eventHandler)

{

if (e == null)

return null;

e.Remove(eventHandler);

return e;

}

internal Delegate[] GetInvocationList()

{

EventHandler temp = this.del;

if (temp == null)

return new Delegate[0];

return temp.GetInvocationList();

}

internal void Invoke(object sender, EventArgs e)

{

EventHandler temp = this.del;

if (temp == null)

return;

foreach (EventHandler eh in temp.GetInvocationList())

{

try

{

eh(sender, e);

}

catch

{

// Do something with exception.

}

}

}

}
This gets you "close", but still has some problems:
1) You don't get the normal delegate semantics. You need to call event.Invoke(), instead of just event().
2) You don't get the readonly semantics for external access.
3) You still can't put Event in an interface.
4) You don't get Invoke protection from external code.
5) The internal for Invoke is a hack. It also means you need to define Event yourself in all assemblies that would use Event.
You may be able to some kind of runtime check, but that would slow your events down.
6) External code can pass around the Event ref - which may not be a good thing.
7) Your "bake" in the EventHandler delegate. Not sure how to make this more generic to handle any delegate. You could use EventHandler<T> is guess.

In the end, I think they made the right choice.

--
William Stacey [MVP]

"Mike" <vi********@yahoo.com> wrote in message news:eA**************@TK2MSFTNGP11.phx.gbl...
|
| "Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
| news:MP************************@msnews.microsoft.c om...
| > Mike <vi********@yahoo.com> wrote:
| >> Personally, "event" seems like a wart and a lot of hacky sugar for very
| >> little gain, and some restrictions that may be limiting.
| >>
| >> I think just plain delegates, and an [Event...] attribute for delegate
| >> fields for tools that like to distingish events would have done just as
| >> well.
| >>
| >> Certainly, there's not much difference bettween typing these two lines
| >> (or
| >> more likely, having the IDE do it for you):
| >>
| >> [Event] public DelegateType Field;
| >> public event DelegateType Field;
| >
| > There's a *very* big different. With the first, *anyone* can change the
| > field, to anything - no restrictions. With the second, you've only got
| > subscribe/unsubscribe. They encapsulate different things.
|
| Yes - I provided a mixed model that isn't exactly what I had in mind - I
| supposed I shouldn't have posted if I wasn't will to put up a design that
| reflected my thinking - I suppose in my copious spare time, I'll try and do
| so. In this case the delegate should be black-boxed by a class (framework
| provided, if desired) that exposes only subscribe/unsubscribe, if that is
| desired, and the attribute belongs on the field/property that returns the
| EventSource, not on the delegate field itself, unless simple, unrestricted
| access is permitted. (I conflated some of the event provider and client code
| in my post.)
|
| m
|
|
| >
| > <snip>
| >
| > --
| > Jon Skeet - <sk***@pobox.com>
| > http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
| > If replying to the group, please do not mail me too
|
|

Mar 13 '06 #14

"Mike" <vi********@yahoo.com> wrote in message
news:eA**************@TK2MSFTNGP11.phx.gbl...

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mike <vi********@yahoo.com> wrote:
Personally, "event" seems like a wart and a lot of hacky sugar for very
little gain, and some restrictions that may be limiting.

I think just plain delegates, and an [Event...] attribute for delegate
fields for tools that like to distingish events would have done just as
well.

Certainly, there's not much difference bettween typing these two lines
(or
more likely, having the IDE do it for you):

[Event] public DelegateType Field;
public event DelegateType Field;

There's a *very* big different. With the first, *anyone* can change the
field, to anything - no restrictions. With the second, you've only got
subscribe/unsubscribe. They encapsulate different things.

Yes - I provided a mixed model that isn't exactly what I had in mind - I
supposed I shouldn't have posted if I wasn't will to put up a design that
reflected my thinking - I suppose in my copious spare time, I'll try and
do so. In this case the delegate should be black-boxed by a class
(framework provided, if desired) that exposes only subscribe/unsubscribe,
if that is desired, and the attribute belongs on the field/property that
returns the EventSource, not on the delegate field itself, unless simple,
unrestricted access is permitted. (I conflated some of the event provider
and client code in my post.)

Your solution seems to intriduce an unnecessary extra object with associated
allocation and deallocation overhead.

The thing to remember is that an event is not an object any more than a
property is - it is just a set of methods to access private fields of the
containing class.

Mar 13 '06 #15

Mike

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:ON**************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uu**************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl...
<snip>
It still requires overriding a concrete class or implementing an interface
to change add/remove behavior.
Sure -- which happens to be the way you implement functionality everywhere
else in the language.
Modifying add/remove behavior is not all that common AFAIKT, and if you want
more control you can just use delegates and your own notification framework
and forego events all-together. In the case of overriding add/remove
behavior, you're "burdening" the control/framework writer, not the
consumer/subscriber.
The CLR itself defines events, there is metadata

The metadata can exist in either scheme, as with [Event...] above.

Certainly it could, but why? For something that is probably more common
than a great many other features(like stackalloc or static classes, for
example,) this lacks any reason. Do you *HAVE* a reason that this is
better? Or do you just think it is because its teh way you expected it to
be?
, an extensible set of accessors, and explicit rules tied to them,

Exactly - those rules need not be there.

They'd clearly have to exist, they'd just be different. Instead of event
metadata, you'd have a rule about the type of event container you'd have
to use or what have you. it's still there.

I think somehow we just violently agreed.

they are as first class as methods, properties, and fields within the
runtime. If you read up on the language, runtime, or anything else it
will become clear.

I understand your viewpoint - but your reply to me seems to be:
"your idea that events should not be first-class is wrong, because they
are" doesn't seem to go anywhere.

You're suggestion here has basically been "its wrong because I say so."

No. I don't beleive I said anything was "wrong" anywhere.
You've offered nothing as far as evidence or reasoning, except that you
weren't aware of something that you really don't need to be aware of.
What, praytell, was that?
Events deserve to be first class features, they offer semantic value and
are quite commonly used, IMHO.
I'm not sure about "deserve", but certainly there are good arguments for
making them first class, enough that the language designers decided to do
so.

This is in contrast to the event where an event declaration goes ahead
and creates lots of crap behind the scenes,
including a property-like definition with add/remove sections that could
easily be normal method invocations.

That is sugar to save you time. Its not like the langauge designers are
going out of hteir way to make sure you don't know about the add/remove
accessors.

It really saves me no time, as the collection classes have implemented
events the way they want, and I just use them.
An alternative need not impact me at all.

it hides things behind a class most users won't realize you can dig into

Well, there's no reason for most users to "dig into" it at all - it just
works, and appears from the client's perspective just like the current
events, with += and the like. If advanced users want to add functionality
to an event (let's say "ClearAll()" or "SetInvokeThreadingMode(...)" or
"SetInvokeExceptionChainMode(...) or whatever) they now have a class to
extend or replace - where with the currnent model add{} and remove{} are
set in stone. (At least from the c#-side, maybe not from the CLR's
perspective.)

This is pretty irrelevent. Is your argument really "it works the same, so
why not?"

Then I really have failed, becuase the point was not to make a argument at
all.
The current model has none of htese features because they aren't needed.
Says who? The only time I could have used "event" as a notification source I
could not, because it was lacking more control.
Luckily, one can happily ignore "event" and use the underlying delegates -
so I have on complaints on my ability to acheive my goals with C#.
However, when one can ignore something in a language and do something that
is more general without *much* cost, it's valid to ask if it should be in
the language.

I'm not saying "event" was wrong, but certainly the lack of "event" is not
in the same league as the lack that other languages features would be - a
gaping hole. Basically, "event" is a very useful second "layer" of language
on top of C# -- as C# does not have macros, a meta-programming model, or
other mechanism for "layering", some features from this "base+1" language
layer will natually become part of the language. (Another example includes
Mozart, which has in interesting layered approach to language design, adding
mutability on top of a functional languages with "slots", and then adding OO
on top of this layer.) The use of Reflection.Emit (and the new, lightweight
versions) is another example -- and although done at runtime by necessity,
many uses of Emit are done on information that is all present at
compile-time, such as using reflection to inspect types that were known at
compile-time and to automatically generate concrete implementations for
certain interfaces.

True - but again, not a problem if they aren't first-class...

Yet you've yet to come up with any reason why it shouldn't be.

I wasn't trying to say would they *shouldn't* be, I was saying why they
"needn't have been".
You can get by with quite a few more general features alone. You can throw
away properties and define a Property<T> type that has optional get & set
methods. You could do away with iterators, return values, operators,
delegates, and a whole host of other things as well. The point of it all
isn't that you *CAN* get rid of it, the point is that it is easier and\or
permits new scenarios with no costs on any level.
You don't really beleive your own slippery slope argument, so why present
the hyperbole?
Most of your litany of features is either completly impossible to
emulate/replace, or only possible at very great cost.
"event" is not in this category, which is the whole point.
People are split? You are the first person I've ever seen suggest events
don't need to be there.
A quick google on the topic has shown otherwise; although I agree I searched
for what I was looking for -- I'm not saying it's a feeling that most c#
programmers hold. Most people wouldn't give them a second thought - I
decsion that I now highly praise them for :)
They are incredibly simple, distinction from delegate and events excluded,
I really don't get your problem with them. You seem just to think they are
a bad idea.

No, I don't -- they just not necessarily the "best" idea, given your
personal view of optimality. Given the same choice to make, I probably could
have been conviced to include the keywork as well.

m

Mar 15 '06 #16

Mike

"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:Xs********************@fe1.news.blueyonder.co .uk...
r

"Mike" <vi********@yahoo.com> wrote in message
news:eA**************@TK2MSFTNGP11.phx.gbl... <lot's snipped> Your solution seems to intriduce an unnecessary extra object with
associated allocation and deallocation overhead.
We're only talking about one object that each event the class handles, most
likely allocated statically.
Plus, if you're that worried about object allocation, chances are there's
well enough lower hanging fruit to deal with in any program, probably by
several orders of magnitute.
The thing to remember is that an event is not an object any more than a
property is - it is just a set of methods to access private fields of the
containing class.

Yes, that is how it is implemented currently.

And a delegate is no more a class than an interface is -- except that a
delegate *is* implemented by creating a seperate class of the same name as
the delegate with an Invoke() method. Is this the only possible
implementation of a delegate?
If I say "c.Click += myMethod;", what do I care if it's through the current
event keyword, or if c.Click is a property that returns a static Event
object that implements the "+" operation?
One may well state that in doing this it may be hard to emulate the *exact*
semantics *as they are now*, but that is something I was not try to state --
only that *similar* semantics brought about by this mechanism *would have
been* good enough, and in many ways more general.

At this point, "event" is obviously the way to go if it happens to do what
you want it to do.

m

Mar 15 '06 #17

> <snip>

It still requires overriding a concrete class or implementing an
interface to change add/remove behavior.
Sure -- which happens to be the way you implement functionality everywhere
else in the language.
Modifying add/remove behavior is not all that common AFAIKT, and if you
want more control you can just use delegates and your own notification
framework and forego events all-together. In the case of overriding
add/remove behavior, you're "burdening" the control/framework writer, not
the consumer/subscriber.

No, modifying add/remove behavior isn't very common, which is why the
add/remove accessors are pretty unknown. That doesn't really relate to
anything at all though. Your point here seems to be "if they want to control
add and remove, let them write their own framework" which is terrible, IMHO.
It's giving false credence to your model since it would only ever come up
with your model. Basic eventing covers it very well without any pointless
complications.

Exactly - those rules need not be there.

They'd clearly have to exist, they'd just be different. Instead of event
metadata, you'd have a rule about the type of event container you'd have
to use or what have you. it's still there.

I think somehow we just violently agreed.

Obviously. You seem upset that something exists yet don't seem to mind a
complicated, multiclass solution that would have to follow as strenous a set
of rules and would have to be defined *IN THE SAME PLACE* to be as
effective, unless of course you are quite happy with a myriad of eventing
systems with slightly different semantics.

I understand your viewpoint - but your reply to me seems to be:
"your idea that events should not be first-class is wrong, because they
are" doesn't seem to go anywhere.

You're suggestion here has basically been "its wrong because I say so."

No. I don't beleive I said anything was "wrong" anywhere.

You seem to imply, deeply, that he current method is wrong...mainly because
you think so. I can't see why you bothered to post at all after your
question was answered if you didn't have an issue with the existing
implementation.

You've offered nothing as far as evidence or reasoning, except that you
weren't aware of something that you really don't need to be aware of.
What, praytell, was that?

Again, no reasons. Are you going to give one?

That is sugar to save you time. Its not like the langauge designers are
going out of hteir way to make sure you don't know about the add/remove
accessors.

It really saves me no time, as the collection classes have implemented
events the way they want, and I just use them.
An alternative need not impact me at all.

It saves you no time because you clearly don't actually write them. Have you
ever written a class that *EXPOSES* events or are you just talking strictly
from teh subscriber side here?

it hides things behind a class most users won't realize you can dig
into

Well, there's no reason for most users to "dig into" it at all - it just
works, and appears from the client's perspective just like the current
events, with += and the like. If advanced users want to add
functionality to an event (let's say "ClearAll()" or
"SetInvokeThreadingMode(...)" or "SetInvokeExceptionChainMode(...) or
whatever) they now have a class to extend or replace - where with the
currnent model add{} and remove{} are set in stone. (At least from the
c#-side, maybe not from the CLR's perspective.) This is pretty irrelevent. Is your argument really "it works the same, so
why not?"

Then I really have failed, becuase the point was not to make a argument at
all.

Yes, you have failed. You seem to be just shooting in the dark agaisnt
something you don't like. You've given vitually no reasoning for it, just
complaints about it.

The current model has none of htese features because they aren't needed.
Says who? The only time I could have used "event" as a notification source
I could not, because it was lacking more control.

Wow. You've needed events *ONCE* and you couldn't use it, so it must be bad
eh? I'm sorry, you really don't seem to have used them enough to even have a
leg to stand on here, no offense intended.
Luckily, one can happily ignore "event" and use the underlying delegates -
so I have on complaints on my ability to acheive my goals with C#.
However, when one can ignore something in a language and do something that
is more general without *much* cost, it's valid to ask if it should be in
the language.
Sure. But was your general solution of use to anyone but you? Were you even
considering events properly? They are a very simple system that works the
vast majority of the time with absolutly no fuss. You hit one issue, the
only time you felt you need to use events, so they must have been done
wrong?

There is definatly more to it than generality, its what is most useful. The
complicated, general solution isn't always the right one, infact it's
probably the wrong one. Simple and static is almost always better than
complicated and general.

I'm not saying "event" was wrong, but certainly the lack of "event" is not
in the same league as the lack that other languages features would be - a
gaping hole. Basically, "event" is a very useful second "layer" of
language on top of C# -- as C# does not have macros, a meta-programming
model, or other mechanism for "layering", some features from this "base+1"
language layer will natually become part of the language. (Another example
includes Mozart, which has in interesting layered approach to language
design, adding mutability on top of a functional languages with "slots",
and then adding OO on top of this layer.) The use of Reflection.Emit (and
the new, lightweight versions) is another example -- and although done at
runtime by necessity, many uses of Emit are done on information that is
all present at compile-time, such as using reflection to inspect types
that were known at compile-time and to automatically generate concrete
implementations for certain interfaces.
I disagree with your first conclusion. That is my #2 complaint with Java, it
lacks first class events and makes up for it with a hackneyed, difficult to
follow system(especially when anonymous classes are involved.) The only
thing worse is the lack of first class properties.

Macro's and meta-programming is something I hope the language never has.
That is almost always the first sign that the language has outgrown its
value. And your uses of reflection don't really apply to much I've done
personally. I don't see the point in inspecting something I knew about
already.

True - but again, not a problem if they aren't first-class...
Yet you've yet to come up with any reason why it shouldn't be.

I wasn't trying to say would they *shouldn't* be, I was saying why they
"needn't have been".

Sure, you've said why they needn't have been: because you have a different
solution. But that isn't a good answer. There are always other solutions,
unless you can show benefit, you didn't prove anything.

You can get by with quite a few more general features alone. You can
throw away properties and define a Property<T> type that has optional get
& set methods. You could do away with iterators, return values,
operators, delegates, and a whole host of other things as well. The point
of it all isn't that you *CAN* get rid of it, the point is that it is
easier and\or permits new scenarios with no costs on any level.
You don't really beleive your own slippery slope argument, so why present
the hyperbole?
Most of your litany of features is either completly impossible to
emulate/replace, or only possible at very great cost.
"event" is not in this category, which is the whole point.

Because I don't know if you actually believe yourself or not either. Almost
everything can be implemented in code, some languages even push it, it is
quite certainly possible to emulate any of these, its all a matter of cost
as you point out. While event is fairly cheap, that doesn't mean that it
shouldn't be moved up into the central language(and, as an argument I never
did make, events are a core part of the concept of a "component" that is a
big piece of the philosophy behind the language.) You have to have either a
technical or philosophical reason for it, merely that it's possible to do
without seems weak to me. Hyperbole, if you will.

People are split? You are the first person I've ever seen suggest events
don't need to be there.

A quick google on the topic has shown otherwise; although I agree I
searched for what I was looking for -- I'm not saying it's a feeling that
most c# programmers hold. Most people wouldn't give them a second
thought - I decsion that I now highly praise them for :)

What did you search for exactly? I see a number of articles on the
difference between delegates and events, but nothing else.

They are incredibly simple, distinction from delegate and events
excluded, I really don't get your problem with them. You seem just to
think they are a bad idea.

No, I don't -- they just not necessarily the "best" idea, given your
personal view of optimality. Given the same choice to make, I probably
could have been conviced to include the keywork as well.

I don't think your method is necessarily the best either. Personally I find
it too complex with no added value.

Mar 15 '06 #18

"Mike" <vi********@yahoo.com> wrote in message
news:uc**************@TK2MSFTNGP11.phx.gbl...

[cut]

And a delegate is no more a class than an interface is -- except that a
delegate *is* implemented by creating a seperate class of the same name as
the delegate with an Invoke() method. Is this the only possible
implementation of a delegate?
If I say "c.Click += myMethod;", what do I care if it's through the
current event keyword, or if c.Click is a property that returns a static
Event object that implements the "+" operation?

[cut]

Language interoperability requires that, at the very least, events are
implemented as the add_X and remove_X methods - You can ask for a change to
what goes on behind that in C# if you want because it's just cosmetic but
changing to a property that contains an event object would break all
existing language interoperability.

Mar 15 '06 #19

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:ua**************@tk2msftngp13.phx.gbl...

<snip>
It still requires overriding a concrete class or implementing an
interface to change add/remove behavior.

Sure -- which happens to be the way you implement functionality
everywhere else in the language.
Modifying add/remove behavior is not all that common AFAIKT, and if you
want more control you can just use delegates and your own notification
framework and forego events all-together. In the case of overriding
add/remove behavior, you're "burdening" the control/framework writer, not
the consumer/subscriber.

No, modifying add/remove behavior isn't very common, which is why the
add/remove accessors are pretty unknown.

Actually it is used by every event in every component in the framework -
that seems pretty common to me!

see
http://msdn2.microsoft.com/en-us/lib...ts(VS.80).aspx

It's the only way to go when you have a large number of events, most of
which will never be hooked up.

Mar 15 '06 #20

William Stacey [MVP]

| Actually it is used by every event in every component in the framework -
| that seems pretty common to me!
| see
|
http://msdn2.microsoft.com/en-us/lib...ts(VS.80).aspx

I don't get it Nick. What are you trying to say here?

Mar 15 '06 #21

"William Stacey [MVP]" <wi************@gmail.com> wrote in message
news:O%****************@TK2MSFTNGP11.phx.gbl...

| Actually it is used by every event in every component in the framework -
| that seems pretty common to me!
| see
|
http://msdn2.microsoft.com/en-us/lib...ts(VS.80).aspx

I don't get it Nick. What are you trying to say here?

Daniel said that modifying add/remove behaviour isn't common but it is for
every component as they all modify it to use a common dictionary rather than
having individual delegate fields.

Mar 15 '06 #22

Mike

"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:b2******************@fe3.news.blueyonder.co.u k...

"Mike" <vi********@yahoo.com> wrote in message
news:uc**************@TK2MSFTNGP11.phx.gbl...

[cut]
And a delegate is no more a class than an interface is -- except that a
delegate *is* implemented by creating a seperate class of the same name
as the delegate with an Invoke() method. Is this the only possible
implementation of a delegate?
If I say "c.Click += myMethod;", what do I care if it's through the
current event keyword, or if c.Click is a property that returns a static
Event object that implements the "+" operation?

[cut]

Language interoperability requires that, at the very least, events are
implemented as the add_X and remove_X methods - You can ask for a change
to what goes on behind that in C# if you want because it's just cosmetic
but changing to a property that contains an event object would break all
existing language interoperability.

I'm not sure why everyone thinks I'm asking for a change in such a used
aspect of C# ex post facto -- as this is (a) not what I want and (b) futile.
I was just saying that if "event" were not there, there already exist other
language features (in concert with tools) that could have acheived similar
(if perhaps not exact) results in a more general and extensible way. Any
functionality not acheived (such as Invoke operation hiding) could be
addressed by simlarly general alternate language features (such as more
flexible field access control), rather than being specific to "event". I
think c# is great and I do not bebrudge its designers for making an
expedient and very workable choice with "event" -- I didn't expect defensive
refactions, especially as I'm usually defending c# myself, as I think it has
in general very "well-balanced" in such choices.

thanks,
m

Mar 15 '06 #23

Mike <vi********@yahoo.com> wrote:

<snip>

I think c# is great and I do not bebrudge its designers for making an
expedient and very workable choice with "event" -- I didn't expect
defensive refactions, especially as I'm usually defending c# myself,
as I think it has in general very "well-balanced" in such choices.

I suspect the reaction was the way it was partly because there's a big
difference between "expedient and very workable" and "a wart and a lot
of hacky sugar for very little gain". Many of us rather like the sugar,
just as many of us like properties even though they offer nothing that
can't be done with get and set methods. (Not that the property syntax
is perfect either, of course - at least in 2.0 you can specify
different access levels, at last...)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 15 '06 #24

"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:Xe******************@fe3.news.blueyonder.co.u k...

"William Stacey [MVP]" <wi************@gmail.com> wrote in message
news:O%****************@TK2MSFTNGP11.phx.gbl...
| Actually it is used by every event in every component in the framework -
| that seems pretty common to me!
| see
|
http://msdn2.microsoft.com/en-us/lib...ts(VS.80).aspx

I don't get it Nick. What are you trying to say here?

Daniel said that modifying add/remove behaviour isn't common but it is for
every component as they all modify it to use a common dictionary rather
than having individual delegate fields.

I'd also bet the framework component's itself are just about the only place
its used, and although the framework is very big, I doubt it stands as much
compared to the rest of the world's .NET codebase. It makes alot of sense
with alot of events and in the rare occasion you need very carefully
designed locking semantics, but beyond that, the everyday user isn't going
to use it, the power user isn't going to use it, pretty much no one will.
The framework also makes extensive use of unsafe code and pinvoke, that
doesn't make it common either.

Mar 16 '06 #25

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:On**************@TK2MSFTNGP11.phx.gbl...

"Nick Hounsome" <nh***@nickhounsome.me.uk> wrote in message
news:Xe******************@fe3.news.blueyonder.co.u k...

"William Stacey [MVP]" <wi************@gmail.com> wrote in message
news:O%****************@TK2MSFTNGP11.phx.gbl...
| Actually it is used by every event in every component in the
framework -
| that seems pretty common to me!
| see
|
http://msdn2.microsoft.com/en-us/lib...ts(VS.80).aspx

I don't get it Nick. What are you trying to say here?

Daniel said that modifying add/remove behaviour isn't common but it is
for every component as they all modify it to use a common dictionary
rather than having individual delegate fields.

I'd also bet the framework component's itself are just about the only
place its used, and although the framework is very big, I doubt it stands
as much compared to the rest of the world's .NET codebase. It makes alot
of sense with alot of events and in the rare occasion you need very
carefully designed locking semantics, but beyond that, the everyday user
isn't going to use it, the power user isn't going to use it, pretty much
no one will. The framework also makes extensive use of unsafe code and
pinvoke, that doesn't make it common either.

If you design a user control and add properties why wouldn't you use the
functionality in the base class? I must admit I haven't until now but I
think that I probably will in future.

I admit that I don't know of any other use for it so if you really want new
functionality perhaps you can just ask for this specific mode of operation
to be built in as an option somehow (an attribute would work).

Mar 16 '06 #26

Daniel O'Connell [C# MVP] <onyxkirx@--NOSPAM--comcast.net> wrote:

Daniel said that modifying add/remove behaviour isn't common but it is for
every component as they all modify it to use a common dictionary rather
than having individual delegate fields.

I'd also bet the framework component's itself are just about the only place
its used, and although the framework is very big, I doubt it stands as much
compared to the rest of the world's .NET codebase. It makes alot of sense
with alot of events and in the rare occasion you need very carefully
designed locking semantics, but beyond that, the everyday user isn't going
to use it, the power user isn't going to use it, pretty much no one will.
The framework also makes extensive use of unsafe code and pinvoke, that
doesn't make it common either.

Personally I regularly change the add/remove behaviour - but only
because the default behaviour isn't nicely thread-safe :(

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 16 '06 #27

Mike

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Mike <vi********@yahoo.com> wrote:

<snip>
I think c# is great and I do not bebrudge its designers for making an
expedient and very workable choice with "event" -- I didn't expect
defensive refactions, especially as I'm usually defending c# myself,
as I think it has in general very "well-balanced" in such choices.
I suspect the reaction was the way it was partly because there's a big
difference between "expedient and very workable" and "a wart and a lot
of hacky sugar for very little gain".

Fair enough :) -- certainly from an emotional standpoint.
I don't think the two statements (or at least the two sentiments) cannot
co-exist, though.
Although I should have been more careful - probably it was overly strong.
Many of us rather like the sugar,
just as many of us like properties even though they offer nothing that
can't be done with get and set methods. (Not that the property syntax
is perfect either, of course - at least in 2.0 you can specify
different access levels, at last...)
Sure - I'm not saying there's isn't a line above which things are certainly
worth it, and I think properties are above it; I think now "events" are
above it, but just barely...

thanks,
m

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Mar 16 '06 #28

Kevin Spencer

Hi Mike,

Sure - I'm not saying there's isn't a line above which things are
certainly worth it, and I think properties are above it; I think now
"events" are above it, but just barely...
Well, performance isn't everything. There is also good reason for adopting
more or less universally-accepted practices. It makes code maintenance
easier for anyone who may have to pick up where someone else left off,
including the original author. And it makes using Reflection much easier
when necessary. Consistency of technique is a human resource-saving
(time-saving) factor.

As we programmers are more or less paid "by the hour" (one way or the
other), anything that optimizes *our* performance is definitely a
consideration with regards to cost!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer

Presuming that God is "only an idea" -
Ideas exist.
Therefore, God exists.

"Mike" <vi********@yahoo.com> wrote in message
news:e9**************@TK2MSFTNGP14.phx.gbl...
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mike <vi********@yahoo.com> wrote:

<snip>
I think c# is great and I do not bebrudge its designers for making an
expedient and very workable choice with "event" -- I didn't expect
defensive refactions, especially as I'm usually defending c# myself,
as I think it has in general very "well-balanced" in such choices.

I suspect the reaction was the way it was partly because there's a big
difference between "expedient and very workable" and "a wart and a lot
of hacky sugar for very little gain".

Fair enough :) -- certainly from an emotional standpoint.
I don't think the two statements (or at least the two sentiments) cannot
co-exist, though.
Although I should have been more careful - probably it was overly strong.
Many of us rather like the sugar,
just as many of us like properties even though they offer nothing that
can't be done with get and set methods. (Not that the property syntax
is perfect either, of course - at least in 2.0 you can specify
different access levels, at last...)

Sure - I'm not saying there's isn't a line above which things are
certainly worth it, and I think properties are above it; I think now
"events" are above it, but just barely...

Mar 16 '06 #29

Mike

Daniel - this thread is luckilly winding down, but I didn't want to leave
this reply completely hanging, so I'll address remaing stuff...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:ua**************@tk2msftngp13.phx.gbl...

<snip>
It still requires overriding a concrete class or implementing an
interface to change add/remove behavior.
Sure -- which happens to be the way you implement functionality
everywhere else in the language.
Modifying add/remove behavior is not all that common AFAIKT, and if you
want more control you can just use delegates and your own notification
framework and forego events all-together. In the case of overriding
add/remove behavior, you're "burdening" the control/framework writer, not
the consumer/subscriber.

No, modifying add/remove behavior isn't very common, which is why the
add/remove accessors are pretty unknown. That doesn't really relate to
anything at all though. Your point here seems to be "if they want to
control add and remove, let them write their own framework" which is
terrible, IMHO.

IMHO, as well. I did not suggest (or didn't think I did) any such thing. I
suggested that they
could make use of nearly equally easy-to-use framework that would exist in a
system sans the event keyword, but possibly with other language mods in
place of "event", but supporting
the event model, as well as non-event code.
Basic eventing covers it very well without any pointless complications.
Agreed.

Exactly - those rules need not be there.

They'd clearly have to exist, they'd just be different. Instead of event
metadata, you'd have a rule about the type of event container you'd have
to use or what have you. it's still there.

I think somehow we just violently agreed.

Obviously. You seem upset

No, I am not upset.
I can't see why you bothered to post at all after your question was
answered if you didn't have an issue with the existing implementation.
I had no question, I just thought it was an interesting topic (current
"event" keyword vs. alternate event implementations) - perhaps it is not.
I guess I should have posted to comp-lang-csharp-random-musings...
It saves you no time because you clearly don't actually write them. Have
you ever written a class that *EXPOSES* events
Of course.

Then I really have failed, becuase the point was not to make a argument
at all.

Yes, you have failed. You seem to be just shooting in the dark
against something you don't like.

Hey, I think you started shooting.

The current model has none of htese features because they aren't needed.

Says who? The only time I could have used "event" as a notification
source I could not, because it was lacking more control.

Wow. You've needed events *ONCE* and you couldn't use it, so it must be
bad eh? I'm sorry, you really don't seem to have used them enough to even
have a leg to stand on here, no offense intended.

Sorry - I should have been more clear. What I said was
"When I could have used 'event' as a notification
source" -- what I meant was
"When I could have used 'event' as a *general* notification
source *outside of the domain of GUI controls*". (A more general
publish/subscribe
scenerio.) All I was saying was I had to abandon the existing language
feature because
it was really close, but not extensible. A alternate event object
implementation could have been extended.
However, I agree that it's not a strong statement from the vantage point of
the existing "event" keyword
for me to say it wasn't useful for something that it wasn't designed for -
execpt that's not the vantage point I had.
There is definatly more to it than generality, its what is most useful.
The complicated, general solution isn't always the right one, infact it's
probably the wrong one. Simple and static is almost always better than
complicated and general.
I would agree with you here in many cases.
I disagree with your first conclusion. That is my #2 complaint with Java,
it lacks first class events and makes up for it with a hackneyed,
difficult to follow system(especially when anonymous classes are
involved.) The only thing worse is the lack of first class properties.
Yes, the anoymous class cruft gets pretty old - at least c# delgates hide
the
class definition from the user.
Macro's and meta-programming is something I hope the language never has.
That is almost always the first sign that the language has outgrown its
value.
I'm not sure I agree with that, exactly, as they are usually an integral
part
of the language from the start, so I'm not sure how the life-cycle
charaterization fits it. But macros can be both incredibly ugly and abused,
as well as extremely useful when they're needed. It's almost the opposite
life-cycle for marco's in the C-like languages -
they appeared first, and then many uses of macros (and typedef) are replaced
by the cleaner generics and/or templates, to the point where c# and Java
don't have macros them at all. (Although I still think Typedef would be nice
to have - even when
generics are a possible fit, you end up with recursive <T...> creep in all
your definitions. At least for
simple cases like defining the size of an integer that may need to change
from 16 to 32 bits, for example, I think typedef is a good fit.)
And your uses of reflection don't really apply to much I've done
personally. I don't see the point in inspecting something I knew about
already.
I was thinking of common examples such as automatically wrapping public
members in possibly renamed
properties (e.g, for O/R mappers or data-binding controls that only look at
properties), providing proxy classes that provide an inplementation for an
interface that the object doesn't natively support, etc.
Again, not that it's the best way in an ideal world to accomplish the task,
it's just what's in the toolbox.
(As well as source-to-source transformation, a la Codesmith, etc.)
IMHO, both solutions have problems.
I don't think your method is necessarily the best either.
I never said it was the best.
Personally I
find it too complex with no added value.

It *is* more complex, but not from the subscriber's POV, which I think is
the important part.
The provider's implemetation can also be mostly pre-baked.

I presented some added value, but I'm okay with someone not agreeing that
the trade-off's are worth it.

thanks,
m

Mar 16 '06 #30