zhztheplayer commented on PR #5698:
URL: 
https://github.com/apache/incubator-gluten/pull/5698#issuecomment-2134349360

   > I agree, each code sync between community and out internal repo takes lots 
time
   
   No real refactors can be done if an OSS takes the rebase effort of forked 
repository into account. We can design some APIs / SPIs and maintain the 
backward compatibility of the then with some well-designed API tests. But it's 
not possible to maintain backward compatibility for forked repos. We can't 
predict how forked code is accessing the base code.
   
   Regarding the case class issue, I am actually a little surprised that we 
have been having so much discussions about it. I recommend one to take some 
time to do some Googles to understand why it's so harmful, if having questions 
about that refactor.
   
   As a developer / committer of Gluten I don't like to be too nitpicking 
either except that the case-class issue is really the one that each developer 
is supposed to be aware of. Especially when that kind of code is written 
against a regular Spark operator (WriteFilesExec), which makes the risk 
increased by 10x.
   
   You can refer to this [code 
example](https://scastie.scala-lang.org/RQVxIXYoQ4qHGKjtWAq1Ew) to see how 
Scala is doing bad on the extending of case classes.
   
   Also, you guys could go through some old commits in Gazelle Plugin (the 
ancestor of project Gluten), which could perfectly tell you a story how we used 
to be suffering from case class inheritances:
   
   1. 
https://github.com/oap-project/gazelle_plugin/commit/54a2fb1899971dce2758942224bea7de4e4336ba
   2. 
https://github.com/oap-project/gazelle_plugin/commit/613d3156f23faf9025c535081037fc74ff4a1445
   3. 
https://github.com/oap-project/gazelle_plugin/commit/91043989f99ca4bf2cdfef96179609e5445ccd35
   
   
   


-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to