Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-7727] Avoid inner classes in RuleExecutor #6319

Closed
wants to merge 8 commits into from

Conversation

Jeffrharr
Copy link
Contributor

Allow composibility of Batch in RuleExecutor be making classes outer.

@chenghao-intel
Copy link
Contributor

Any background why we should expose the Batch? Per my understanding, we'd better keep the minimizing the class visibility as much as possible in design.

@Jeffrharr
Copy link
Contributor Author

In my opinion, it seems like a poor fix to the issue of composing Batches
in different instances and there is likely a much better way to refactor
the class to get the desired behavior (although I don't personally know how
yet). It was labeled as starter and making the classes outer was the
proposed fix.
On May 24, 2015 11:48 PM, "Cheng Hao" notifications@github.com wrote:

Any background why we should expose the Batch? Per my understanding, we'd
better keep the minimizing the class visibility as much as possible in
design.


Reply to this email directly or view it on GitHub
#6319 (comment).

@chenghao-intel
Copy link
Contributor

Oh, sorry, I didn't see the description of the jira. I will jump there to give more comments.

@evacchi
Copy link
Contributor

evacchi commented May 28, 2015

@chenghao-intel although Batch may not be supposed to be public, inner classes are still bad when it comes to sharing code (because they are not static inner). I'd advise to make them at least inner to a companion object; see PR #6349

@@ -61,7 +62,7 @@ class Analyzer(
*/
val extendedResolutionRules: Seq[Rule[LogicalPlan]] = Nil

lazy val batches: Seq[Batch] = Seq(
lazy val batches = Seq(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add the explicit type back?

@rxin
Copy link
Contributor

rxin commented May 30, 2015

LGTM other than that explicit type.

@rxin
Copy link
Contributor

rxin commented May 30, 2015

Jenkins, test this please.

@SparkQA
Copy link

SparkQA commented May 30, 2015

Test build #33816 has finished for PR 6319 at commit ce264cb.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
    • case class Batch[TreeType <: TreeNode[_]](name: String, strategy: Strategy, rules: Rule[TreeType]*)
    • abstract class RuleExecutor[TreeType <: TreeNode[_]] extends Logging

@marmbrus
Copy link
Contributor

ping, mind bringing this up to date?

@rxin
Copy link
Contributor

rxin commented Jul 18, 2015

Jenkins, ok to test.

@marmbrus
Copy link
Contributor

ok to test

@SparkQA
Copy link

SparkQA commented Jul 22, 2015

Test build #1174 has finished for PR 6319 at commit 0c38212.

  • This patch fails to build.
  • This patch merges cleanly.
  • This patch adds the following public classes (experimental):
    • case class Batch[TreeType <: TreeNode[_]](name: String, strategy: Strategy, rules: Rule[TreeType]*)
    • abstract class RuleExecutor[TreeType <: TreeNode[_]] extends Logging

@marmbrus
Copy link
Contributor

marmbrus commented Sep 3, 2015

@His-name-is-Joof, thanks for working on this. I propose we close this issue until you have time to fix the build failures and bring the code up to date.

@asfgit asfgit closed this in 804a012 Sep 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants