diff --git a/docs/csharp/modern-events.md b/docs/csharp/modern-events.md index 1503d8bfa8289..6c2e09c3760b7 100644 --- a/docs/csharp/modern-events.md +++ b/docs/csharp/modern-events.md @@ -10,7 +10,7 @@ ms.subservice: fundamentals The previous article discussed the most common event patterns. .NET Core has a more relaxed pattern. In this version, the `EventHandler` definition no longer has the constraint that `TEventArgs` must be a class derived from `System.EventArgs`. -This increases flexibility for you, and is backwards compatible. Let's start with the flexibility. The implementation for uses a method defined in one method: , which creates a shallow copy of the object. That method must use reflection in order to implement its functionality for any class derived from `EventArgs`. That functionality is easier to create in a specific derived class. That effectively means that deriving from System.EventArgs is a constraint that limits your designs, but doesn't provide any extra benefit. In fact, you can change the definitions of `FileFoundArgs` and `SearchDirectoryArgs` so that they don't derive from `EventArgs`. The program works exactly the same. +This increases flexibility for you and is backward compatible. Let's start with the flexibility. The implementation of uses a method defined in : , which creates a shallow copy of the object. That method must use reflection in order to implement its functionality for any class derived from `EventArgs`. That functionality is easier to create in a specific derived class. That effectively means that deriving from System.EventArgs is a constraint that limits your designs, but doesn't provide any extra benefit. In fact, you can change the definitions of `FileFoundArgs` and `SearchDirectoryArgs` so that they don't derive from `EventArgs`. The program works exactly the same. You could also change the `SearchDirectoryArgs` to a struct, if you make one more change: