an event does not have a priority. Listeners have priority

True! I wasn't sure though. Worth renaming to "listener's priority" then?

+1 on this. As it stands right now there is no way to inspect any given implementation of EventDispatcherInterface and see a listener's priority. You can request getListeners(), but it is simply an array of the listeners with no guarantee of priority being the array key (in fact, it is impossible to simply indicate the priority as an array key anyway, since multiple listeners can have the same priority).

I think the good solutions to this require a BC break (on the interface and the default implementation) to change the getListeners() return contract. Essentially, we would have to force retention of priority on the EventDispatcherInterface.

One way to do this is to change the EventDispatcherInterface to be explicit regarding the array structure that is returned by getListeners() that MUST expose priorities of listeners...

<?php

array(
  "event.name" => array( 
    10 => array(
        "listener1",
        "listener2",
        "etc"
    )
  )
)

Internally, the current implementation of EventDispatcher actually stores the listeners like the code above, but it then does a bunch of logic to sort it (and flatten it) before it returns it to you in ->getListeners(). It would be much better from an introspection point of view if we could get that array without first removing the information of the set priorities number.

Any other ideas?

I must admit, that I don't really understand the use case. What should this be good for, except debugging? I mean a listener shouldn't need to know any other listener, least of all their priority. Only the dispatcher needs to know. This said I don't think a BC break is reasonable...

However, have you seen egulias/listeners-debug-command-bundle already? It provides a command container:debug:listeners, that returns every known listener including their priorities. Maybe that is already enough for your purpose. If not, have a look at its code. It extracts the relevant information directly out of the container, what makes sense, because that's where they come from.
Just reuse, what is already there: https://github.com/egulias/ListenersDebug/blob/master/Listener/ListenerFetcher.php#L22

It's true that this is pretty much only for debugging. There could be some uses in a situation where you might want to dynamically add an event to the dispatcher above or below an already registered event (which you can't do without knowing its priority).

That being said, I think you are right in that it's not worth a BC-break, especially since the use cases are so small / rare.

It's purely a "DX" ticket. Often I need to create an event but I am unsure what priority to set it as. If I could just see a list of the listeners and their priority number, I could get it to the right priority without a bunch of trial and error. Thanks for that bundle link, I definitely did not know about it.

Ping @egulias

Thanks @aferrandini for the ping.
HI @christickner , the use case during development may not be so small if you have a heavy listeners infrastructure like e.g eZPublish who has the command required by default.
That being said, as @kingcrunch stated you can use the library inside your listeners. Beware that inspecting the whole container can be an expensive task to do during a request, I would try to avoid it. Or just doing it once, with a CompilerPass.

There is no need of a BC to implement this, we don't need to modify the interface.

@ManInTheBox, if you're trying to implement a Priority column in the profiler, then you could cover #11915 too.

any news on this one ?

I'm closing this issue as "fixed". As some people said, you only need the listener priority for debug purposes. The redesigned profiler already includes this information in the events panel.