Github user tdas commented on the issue:
https://github.com/apache/spark/pull/13998
If the default method implementation preserves earlier behavior, can you
give a concrete scenario where this would break? If not, I see no cost in
converting to abstract class, and potential benefit in future.
Here is an example from my side. Let's say for some reason we want in the
future the system to automatically commit synchronously the read offsets. That
can be part of the ConsumerStrategy but cannot be implemented using custom
onStart only. We can extend the ConsumerStrategy abstract class to have a
overridable flag.
```
abstract class ConsumerStrategy {
def shouldCommitOffsets(): Boolean = false // default implementation
preserves behavior.
...
}
```
Current implementations will not break, neither compile time, nor runtime.
Anyone who implemented ConsumerStrategy can take advantage of the new
ConsumerStrategy by override the method to return true. People can also wrap
their existing custom ConsumerStrategy inside a wrapper strategy that sets that
method to return true. All of this without having think about a new interface.
Its annoying if such small but useful additions require adding whole another
interface, when it can be very easily done this way.
Just to be clear, I am not proposing that we WILL do it this way in the
future. All I am proposing is that having it as `abstract class` instead of
`trait` keeps the possibilities open for the future.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
