Github user vanzin commented on the pull request:
https://github.com/apache/spark/pull/5335#issuecomment-92103902
That aproach would be a lot more complicated. The first reason why it would
be complicated is that you'd need an uber-constructor in SparkContext that
takes all the initialized internal values. Unless there's some fancy Scala
feature I'm not aware of, that in itself is scary as hell, and would mean the
other constructors would be similarly ugly in that they'd have to call the
companion object.
It would also cause (even more) duplication of the declaration of these
things, since they'd have to be declared in the companion object's method too.
Finally, it would complicate `stop()`, because it would have to either be
copy & pasted into the companion object so that it cleans up after an
exception, or you'd need a stop() method in the companion object that takes all
arguments as parameters, so that the SparkContext class can call it.
So while I would love to simplify the code in SparkContext, the alternative
suggestion, as far as I can see, does nothing towards that.
And that's why I chose private vars. It's not optimal, and I really wish
Scala would allow me to initialize a val after its declaration, like Java does.
But it's the easiest approach, and it doesn't expose any mutable SparkContext
state that wasn't already exposes before.
---
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]
