Github user srowen commented on a diff in the pull request:

    https://github.com/apache/spark/pull/12157#discussion_r58719827
  
    --- Diff: core/src/main/scala/org/apache/spark/rdd/HadoopRDD.scala ---
    @@ -53,14 +53,22 @@ import org.apache.spark.util.{NextIterator, 
SerializableConfiguration, ShutdownH
     /**
      * A Spark split class that wraps around a Hadoop InputSplit.
      */
    -private[spark] class HadoopPartition(rddId: Int, idx: Int, s: InputSplit)
    +private[spark] class HadoopPartition(rddId: Int, override val index: Int, 
s: InputSplit)
       extends Partition {
     
       val inputSplit = new SerializableWritable[InputSplit](s)
     
    -  override def hashCode(): Int = 41 * (41 + rddId) + idx
    +  override def hashCode(): Int = 41 * (41 + rddId) + index
     
    -  override val index: Int = idx
    +  def canEqual(other: Any): Boolean = other.isInstanceOf[HadoopPartition]
    +
    +  override def equals(other: Any): Boolean = other match {
    +    case that: HadoopPartition =>
    +      super.equals(that) &&
    +        (that canEqual this) &&
    +        index == that.index
    --- End diff --
    
    Not sure who else may have an opinion ... @andrewor14 ? @vanzin ? 
    
    A key question here is whether `Partition`s should have custom `equals` 
semantics. They don't know and thinking about it not sure they should. At least 
it would have to depend in all cases on their parent RDD. It raises the 
question, why is `hashCode` alone defined for them? it's not technically wrong 
but not clear what purpose it serves.
    
    Still, I think it's safe to leave `equals` and `hashCode` semantics alone 
in `Partition` classes. Your cleanups here are OK, as are fixes in other files, 
as is the idea of a style rule that requires `hashCode` with `equals` (but not 
vice versa; the reverse is possibly legitimate, if odd)


---
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]

Reply via email to