Github user tdas commented on the pull request:
https://github.com/apache/spark/pull/1717#issuecomment-57538997
I thought about this a little bit more.
@sjbrunst That is a possibility. But I dont want to add two new sets of
methods ( 2 x ( 4 + 4 ) new methods). Also, now that I think about it, we kind
of dont want to take the responsibility of specifying the ordering logic of
twitter4j's API. Maybe twitter4j hasnt specified the logic for certain reasons?
Maybe the ordering is subject to change in the future?
As it is, we (spark team), think twice about exposing third party data
structures through our API for future stability. This is because
(i) API gets tied to specific implementation. Exposing FilterQuery is sort
of violating that thought already. What if in future we want to not use
Twitter4j (Twitter API changes, and Twitter4j does not get updated)? What if we
need to make a completely different implementation of twitterStream not using
twitter4j.
(ii) Binary compatibility. I dont know of Twitter4j maintains binary
compatibility across versions. This ties
Let me think about this a little bit more, and consult my colleagues as
well. Any thoughts from you guys?
---
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]
