HeartSaVioR commented on code in PR #50348:
URL: https://github.com/apache/spark/pull/50348#discussion_r2011212796
##########
connector/kafka-0-10-sql/src/main/scala/org/apache/spark/sql/kafka010/KafkaOffsetReaderAdmin.scala:
##########
@@ -535,7 +535,7 @@ private[kafka010] class KafkaOffsetReaderAdmin(
var attempt = 1
var lastException: Throwable = null
while (result.isEmpty && attempt <= maxOffsetFetchAttempts
- && !Thread.currentThread().isInterrupted) {
+ && !Thread.currentThread.isInterrupted) {
Review Comment:
> The latter is idiomatic Scala because it conforms to the uniform access
principle. This principle states that one should be able to change an object
member from a field to a non-side-effecting method and back without affecting
clients that access the member. Consequently, Scala encourages to define such
"property" methods without a () parameter list whereas side-effecting methods
should be defined with it. Methods defined in Java cannot make this
distinction; for them a () is always mandatory. So Scala fixes the problem on
the client side, by allowing the parameterless references. But where Scala
allows that freedom for all method references, Scala 3 restricts it to
references of external methods that are not defined themselves in Scala 3.
If you see the origin thread, the definition of "pure" method is not super
obvious; it's not something compiler would be able to catch and it's mostly on
human's justification. This is just a homework Scala left to us and I don't
really like the fact Scala makes such an ambiguity.
Continuing from there, I'd rather interpret this as Java is just excluded
from the enforcement. It is still arguable what is "pure" method and everyone
has every different opinions. Thread.currentThread is a native method, and it's
not super obvious that there is no side-effect.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
