Github user pwendell commented on the pull request:
https://github.com/apache/spark/pull/4111#issuecomment-70743103
Whether we use a builder pattern vs. adding more constructors is slightly
orthogonal to what I was saying.
I was saying that it would be good if there was some way to avoid making
the user who instantiates a SparkContext have to explicitly identify listeners
in compiled code. It would be more flexible if e.g. a packager could add
listeners that will always be attached in a specific environment. Since
listeners are a semi-public integration point, this seems reasonable to have a
hook here.
Having builder-style constructors for SparkContext is a separate proposal.
In the past we've tried to put as much of the logic as possible into
configurations and generally avoid having complex constructors. The thinking
was it's not good to have two disparate ways of doing configuration (what
happens if I have spark.home in a config and then I manually set sparkHome,
etc, can be confusing). That's something we could look at separately, though,
if we want to go away from the current approach.
---
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]
