The reason for having two separate interfaces is developer API backwards-compatibility, as far as I know. SparkFirehoseListener came later.
On Tue, Oct 13, 2015 at 4:36 PM, Jakob Odersky <joder...@gmail.com> wrote: > the path of the source file defining the event API is > `core/src/main/scala/org/apache/spark/scheduler/SparkListener.scala` > > On 13 October 2015 at 16:29, Jakob Odersky <joder...@gmail.com> wrote: > >> Hi, >> I came across the spark listener API while checking out possible UI >> extensions recently. I noticed that all events inherit from a sealed trait >> `SparkListenerEvent` and that a SparkListener has a corresponding >> `onEventXXX(event)` method for every possible event. >> >> Considering that events inherit from a sealed trait and thus all events >> are known during compile-time, what is the rationale of using specific >> methods for every event rather than a single method that would let a client >> pattern match on the type of event? >> >> I don't know the internals of the pattern matcher, but again, considering >> events are sealed, I reckon that matching performance should not be an >> issue. >> >> thanks, >> --Jakob >> > >
