Events in C# 3.5 - Anything New?

[Smithers]

Moving from .NET 1.1 to 2.0, we gained the generic System.EventHandler<T>
which makes our lives easier when it comes time to implement an event.

Now we're getting .NET 3.5 soon and I'm wondering of there are any new
event-related features or capabilities in 3.5.

Thanks!

 

[Jon Skeet [C# MVP]]

Moving from .NET 1.1 to 2.0, we gained the generic System.EventHandler<T>
which makes our lives easier when it comes time to implement an event.

Now we're getting .NET 3.5 soon and I'm wondering of there are any new
event-related features or capabilities in 3.5.

Well, delegates are the basis of events, and lambda expressions make
delegate instance creation easier.

On the library front, WPF changed how events are handled in UI, with
"routed events" - look them up for more information - but that's not
really anything to do with events in C# as a language.

 

[Brian Gideon]

Moving from .NET 1.1 to 2.0, we gained the generic System.EventHandler<T>
which makes our lives easier when it comes time to implement an event.

Now we're getting .NET 3.5 soon and I'm wondering of there are any new
event-related features or capabilities in 3.5.

Thanks!

These version numbers are getting confusing. I believe it's C# 3.0
that ships with .NET 3.5. C# 2.0 shipped with .NET 3.0 and .NET 2.0.
I still don't buy the reasoning behind giving .NET 3.0 a newer major
version number. It would have made more since to call it .NET 2.5.

 

[UL-Tomten]

These version numbers are getting confusing. I believe it's C# 3.0
that ships with .NET 3.5. C# 2.0 shipped with .NET 3.0 and .NET 2.0.
I still don't buy the reasoning behind giving .NET 3.0 a newer major
version number. It would have made more since to call it .NET 2.5.

So you consider 2.5 to be halfway between 2.0 and 3.0? Please supply
rationale that doesn't include the word Apple.

 

[Brian Gideon]

So you consider 2.5 to be halfway between 2.0 and 3.0? Please supply
rationale that doesn't include the word Apple.

2.1, 2.5, or whatever. Just something other, but less than 3.0. That
way 3.0 would have been available when a new major version number was
really justified. The official 3.5 release is more deserving of a new
major version number than the official 3.0 release IMHO.

I'll turn the question around on you. Do you consider the official
3.5 release (from 3.0) as being only half as significant compared to
the official 3.0 release (from 2.0)?

 

[GlennDoten]

2.1, 2.5, or whatever. Just something other, but less than 3.0. That
way 3.0 would have been available when a new major version number was
really justified. The official 3.5 release is more deserving of a new
major version number than the official 3.0 release IMHO.

I'll turn the question around on you. Do you consider the official
3.5 release (from 3.0) as being only half as significant compared to
the official 3.0 release (from 2.0)?

What threw me was that 3.0 is sort of a parallel release to 2.0, since
3.0 contains the exact same installer as 2.0 has. This notion of 3.0
being layered on top of 2.0 like this was pretty foreign to me.

It would have made more sense to me if the 2.0 assemblies that shipped
with 3.0 had their version numbers bumped to 3.0. Then ship those plus
the new assemblies (also versioned at 3.0) and call the whole thing 3.0.
Even though none of the bits in the 2.0 assemblies were changed, and
this would waste a little disk space for systems running the "old" 2.0
plus this newly packaged 3.0. But, what's done is done and we can't
change it!

But why the hell call the next release 3.5? What happened to 3.1, 3.2,
3.3, and 3.4? Now that REALLY makes no sense to me!

Personally, I have no problem with subcomponents or included
technologies (or whatever) like C# having their own version number like
1.0, 2.0, and 3.0. Getting C# 3.0 with .NET 3.5 is not confusing to me.
There's plenty of precedent for that. Theoretically, C# is not "part" of
..NET, but I suspect that for the next couple of years anyhow that C#
will be released only as a "subcomponent" of .NET.

 

[UL-Tomten]

But why the hell call the next release 3.5? What happened to 3.1, 3.2,
3.3, and 3.4? Now that REALLY makes no sense to me!

Well, that's the Apple software numbering scheme I was hinting at
earlier[1]. It's a mix between incremental numbers and decimal
numbers. But, to be fair, the inspiration might have from X-Men[2].

1: <http://en.wikipedia.org/wiki/Software_versioning#Apple_2>
2: <http://dvd.ign.com/articles/383/383658p1.html>

 

[GlennDoten]

But why the hell call the next release 3.5? What happened to 3.1, 3.2,
3.3, and 3.4? Now that REALLY makes no sense to me!

Well, that's the Apple software numbering scheme I was hinting at
earlier[1]. It's a mix between incremental numbers and decimal
numbers. But, to be fair, the inspiration might have from X-Men[2].

1: <http://en.wikipedia.org/wiki/Software_versioning#Apple_2>
2: <http://dvd.ign.com/articles/383/383658p1.html>

Regardless of what Apple has done to, IMO, pervert version numbers (!)
to my mind 3.5 is not "halfway" between 3.0 and, what, 3.9? How is 3.5
"halfway" between 3.0 and 3.23?

I dunno, I still think the next release of .NET 3.0, if it contains
incremental changes should be called 3.1 and if it contains so-called
"major" changes then 4.0. The concept is so simple yet companies feel
the need to cloud the issue.

Next some marketing guru will want to call it MS.NET 2007 then MS.NET
2007 Plus and who knows what. Which actually I personally don't mind
because they still have "real" version numbers like 3.0, 3.1, and 4.0. I
refer to such named products as VS 7.1, VS 8.0, SQL 8.0, SQL 9.0, etc.
It keeps marketing's ambiguous names out of it. And they only name them
that way to try and get you to upgrade: "Oh you're running SQL 2000?
What an ancient piece of crap that is! You need to upgrade to SQL 2005,
post-haste! Don't you know it is 2007, after all?" They can't as easily
do a mind-sell when it's referred to as SQL 8.0. In fact, I'm surprised
that the .NET Framework variants have survived these marketing names for
this long.

 

[Smithers]

<snip>

<< Next some marketing guru will want to call it MS.NET 2007 then MS.NET
2007 Plus and who knows what... >>

What I'm more concerned about is the possibility that the morons who program
progress bars into installation packages will get involved in the version
numbering game. Have you ever noticed progress bars that gradually increment
to 100%. Then after a second or two you get a brand new progress bar that
starts all over again and gradually increments to 100%. This can go on and
on and on... with the progress bars losing all credibility or meaning. Maybe
when we get to .NET version 100 (which might be within a version or two
after 3.5 is released), they might start over with version numbers... maybe
even filling in the gaps... .NET 1.2, then .NET 2.1... 3.1... 3.6....

-S

 

[UL-Tomten]

What I'm more concerned about is the possibility that the morons who program
progress bars [...]

This reminds me of the progress bar in some version of Internet
Explorer 6, I think. When it didn't know the content-length of a HTTP
response, and/or was waiting for a response the finish time of which
was inherently unknown, it had a really interesting progress bar
approach: it would increment more and more slowly, thus quickly
reaching 50%, but never reaching 100%[1]. I think this, from a
psychological end-user-experience standpoint, is quite interesting.
The parallel in this case could be .NET 4.0, 4.2, 4.3, 4.3.2, etc.

http://en.wikipedia.org/wiki/Zeno's_paradoxes#Achilles_and_the_tortoise

 

[Mattias Sjögren]

But, to be fair, the inspiration might have from X-Men[2].

Ha! Still, it's better than the numbering of the Naked Gun movies. <g>



Mattias