.Add and .Remove on events…

Moo asked:

Why can't we have .Add and .Remove aswell as += and -= operations after all its just a collection, I was rather supprised that this method wasn't actually available for adding event handlers.

One of our design goals is not to have more than one way of doing something (in contrast to Perl's tmtowtdi). If there are two different ways of doing something, developers need to learn both ways and understand that they are equivalent. That makes their job more complex without any real benefit.

Another area that this shows up is on delegates. Since C# has a special syntax for invoking delegates, we don't let you call Invoke() directly.

Comments (12)

  1. Dumky says:

    I understand why only one way of invoking delegates makes sense.

    But how did you choose between the MyDelegate(params) format and the MyDelegate.Invoke(params)?

    I would argue that the syntax that was chosen is rather confusing and using the "Invoke" method would have been simpler.

  2. Louis Parks says:

    Don’t you consider for and foreach two ways of doing the same thing? Why include foreach (which you can do with for) but not include .Add and .Remove (which you can do with += or -=)?

  3. Eric says:

    On the delegate question, we wanted calling a delegate to be more "built in".

    For and foreach do overlap, but not totally. You can foreach over something that doesn’t expose a concept of indexing, such as a binary tree or a database table.

  4. Shane King says:

    You can go even further than that. Why include for, foreach, switch, while and do/while at all, when they’re really just fancy layers on top of a bunch of if and/or goto statements?

    The answer is that sometimes it makes the programmer’s job *easier* if they have more than one way to do it. That should be the prime consideration – what makes the programmers job easier, not blind ideology.

  5. moo says:

    I would like to see the ability to pass a set property as a parameter to be set just like the get can be used as a get in a parameter in a method call. I think this would be a more natural way of using such constructs.

    Yes I am aware that they are just methods in disguise, but why not have the abstraction of a field which they are behaving like (except in the case of setting as an argument).

    Another issue is the new aliases for namespaces using :: notation. Why not just keep the . dot notation isntead of now introducing more risks of typos.

  6. Val Savvateev says:

    [One of our design goals is not to have more than one way of doing something]

    While this is a quite valid goal, I’d say that operators make perfect case for an exception in this rule. Just like it’s always a good idea to have Compare method to support == operator, it may also be a good idea to have counterpart methods for each, or at least the most significant, operators.

    Besides, in environments like .NET I’d expect all the features provided by the framework be equally easily accessable through the object model. Operator overloading in many cases is just a programming language feature. Thus, if we said that certain feature can only be accessed through the use of an operator, that would put major constraints on design of the other languages consuming the framework, or make the source code less transferrable.

  7. moo says:

    Anonmyous methods which only server to help the lazy developers that are high risk due to such lazyness. Are these not adding a different way of using Event Handlers, you can specify it formally with a name and anonymously. That to me would cound as more than one way to be an event handler.

    Generics and colletions, will the current collections be depreciated and usage of generic collections encouraged or would this count as another 2 ways of having collections?

  8. moo says:

    How does one UNSUBSCRIBE (unwire) an anonymous method, we dont know the internal ID thats assigned to this so how is this possible? I think thats where it gets MESSY.

Skip to main content