Proposal: Parameterised Events like indexers

[nikibobi]

I am proposing events with parameters using a syntax similar to indexer properties but for events. In a lot of cases event handler code contains multiple actions that handle only part of the input. This is also bad because it violates the single responsibility principle. Either there is code that does different things or code that ignores the event in certain cases.
Here is an example with keyboard input:

class Keyboard
{
    private IDictionary<Keys, EventHandler> keyPressed = new Dictionary<Keys, EventHandler>();

    public event EventHandler KeyPressed[Keys key]
    {
        add
        {
            keyPressed[key] += value;
        }
        remove
        {
            keyPressed[key] -= value;
        }
    }

    public void OnKeyPressed(Keys key)
    {
        if (keyPressed.ContainsKey(key))
        {
            keyPressed[key]?.Invoke();
        }
    }
}

And later from outside the class:

int x = 0, y = 0;
var keyboard = new Keyboard();
keyboard.KeyPressed[Keys.W] += () => Console.WriteLine("up");
keyboard.KeyPressed[Keys.W] += () => y++;

keyboard.OnKeyPressed(Keys.A); // event handler for W is not called
keyboard.OnKeyPressed(Keys.W); // both W handlers are called

keyboard.KeyPressed[Keys.A] += () => x--;
keyboard.KeyPressed[Keys.S] += () => y--;
keyboard.KeyPressed[Keys.D] += () => x++;

I also suggest some kind of shorthand for this where the compiler handles the backing field and adding/removing event handlers.
I know this is not perfect and I would like to hear what everyone thinks and discuss it.

[CyrusNajmabadi]

This is more of an api decision vs a language decision. Someone could expose events in this fashion by just doing:

keyboard.AddKeyPressedHandler(Keys.A, () => whatever);

Besides. The APIs and patterns around events have been shipping for 15+ years now. They're not going to realistically change in any API. So making this sort of language change won't really be that helpful since 99% of all code out tehre would never be able to benefit from it.

[MkazemAkhgary]

This is actually nice idea, very very good for keeping your control classes nice and clean. you don't have to write event for every functions that you want, its all in one event!

@CyrusNajmabadi alternatives exist, but this will be the syntactic sugar for those, this will also encourage people to use this pattern and syntax because of how short and concise it is.

making this sort of language change won't really be that helpful since 99% of all code out there would never be able to benefit from it.

New APIs can get benefit from it. why keep carrying things from stone age?

Yes, its unlikely that current APIs especially standard ones change to this pattern but that doesn't diminish value of this proposal.

[CyrusNajmabadi]

New APIs can get benefit from it. why keep carrying things from stone age?

Because the existing systems work well enough, and are well understood enough by the community and ecosystem. They're not actually broken, and these proposals don't add enough value to warrant moving away from the existing systems that serve hte problem space in a well enough manner.

Yes, its unlikely that current APIs especially standard ones change to this pattern but that doesn't diminish value of this proposal.

Yes, that does diminish the value of the proposal. :) In general we don't like to add new things that affect API design just because they're slightly newer and slightly shinier. We do it when there's a lot of value to be had: Extensions. Async (which only tangentially affects the design through the Task type). Generics. Tuples, etc.

These cases were done because there was subtantial benefit to the entire ecosystem, and there was the strong belief (that has been borne out) that these features would get large amounts of adoption and would become 'the way' for ohw APIs would be done. They also tended to address areas that were extremely weak beforehand and which people were not satified with the existing solutions for.

Ths is not the case with events. I have no complaint about the feature itself. It seems... ok. Makes some tiny event cases a bit nicer... that's nice. It simply is not punching hard enough to warrant this. We don't have events like this in .Net. So we'd have to define them. And then support them in all our languages. And we don't actually have anyone in the API sphere asking for this. I.e. the existing .net gui frameworks (or other frameworks using events) are not asking for this. So they're not going to adopt this. So we're going to be adding a feature for what purpose? It will be a huge cost, with very little benefit to come out of it.

That's not a good approach to language design.

[ufcpp]

using System.Reactive.Linq;

Observable.FromEventPattern(typeof(Keyboard), "KeyPressed").Where(e => e.EventArgs.Key == key)

[MkazemAkhgary]

@ChitraKoppolu Your statements are correct, I wish I could like this proposal 100 times to fulfill need for adopting it :)

[CyrusNajmabadi]

@MkazemAkhgary What statements are you referring to?

[nikibobi]

Thanks for the feedback. I am not proposing to change existing event APIs but just to add this language feature. For example indexers and operator overloading aren't used every day and you rarely see them used in .Net, but are still useful and are part of the language.
Also such APIs can be exposed without conflict with existing ones. For example a .Net keyboard event pases a KeyEventArgs to the handler. But if it's using a parameterised event it doesn't have to because the key is baked in.

[MkazemAkhgary]

My bad english. I mean your remarks, things you said :) @CyrusNajmabadi

[CyrusNajmabadi]

Thanks for the feedback. I am not proposing to change existing event APIs but just to add this language feature.

I understand that. :) My point is that such a thing is highly unlikely to get traction. You need a large set of API authors who want this feature in order to make it worthwhile to do.

For example a .Net keyboard event pases a KeyEventArgs to the handler. But if it's using a parameterised event it doesn't have to because the key is baked in.

I get how the feature would work :) And i would certainly have no problem with it if this was V1 of the langauge and framework. However, let's just look at your example. Say we added this. Then what? The .net keyboard API already has a way to do eventing. So it wouldn't do any work here. So users would not benefit from this.

[Thaina]

Feel like we need return ref and named indexer here

class Keyboard
{
    private RefDictionary<Keys, EventHandler> keyPressed = new RefDictionary<Keys, EventHandler>();

    public ref EventHandler KeyPressed[Keys key]
    {
        get
        {
            if(!keyPressed.ContainsKey(key))
                keyPressed[key] = (obj,ea) => {};

            return ref keyPressed[key];
        }
    }

    public void OnKeyPressed(Keys key)
    {
        if (keyPressed.ContainsKey(key))
            keyPressed[key]?.Invoke();
    }
}