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

Use named parameters for ib.contract.XXX #137

Open
tredondo opened this issue Dec 7, 2018 · 4 comments
Open

Use named parameters for ib.contract.XXX #137

tredondo opened this issue Dec 7, 2018 · 4 comments

Comments

@tredondo
Copy link
Contributor

tredondo commented Dec 7, 2018

The long list of parameters for various contract types is unwieldy, and also inconsistent in the parameter order:

future: symbol, expiry, currency, exchange, multiplier
fop: symbol, expiry, strike, right, multiplier, exchange, currency

Using destructured parameters would make calls consistent, and much less error-prone:

ib.contract.future({
  symbol: 'YM',
  expiry: '...',
  multiplier: 5,
  exchange: 'GLOBEX',  // for some reason the default exchange for futures is ONE
});

I'm writing a function that parses strings into contract and it's a long switch statement right now because of the variable parameter order.

@pilwon
Copy link
Owner

pilwon commented Jun 22, 2019

@meteorpublish I agree this change will make writing contracts more flexible and easier to read, however it'll be a breaking change. Any suggestion for introducing this without touching existing API?

@tredondo
Copy link
Contributor Author

tredondo commented Jul 5, 2019

Well, since the package is at v0.x, its API is not really guaranteed per semver anyway. One suggestion would be to release v1, rewritten using ES Modules, and with named parameters.

For v0.3, could ib.contract be overridden to take named parameters, e.g.

ib.contract({ type: 'stock', symbol: 'AAPL' })

Otherwise, methods with an O (for "object") suffix could be used:

ib.contract.fopO({ symbol: 'ES', expiry: '20190920', strike: ..., })

@pilwon
Copy link
Owner

pilwon commented Jul 12, 2019

@meteorpublish Yes, you're right about v0.x. I however still wish to maintain this library that doesn't surprise existing users unless it's absolutely necessary. I prefer the cleaner ib.contract({ ... }) option.

@tredondo
Copy link
Contributor Author

tredondo commented Mar 4, 2020

@pilwon: do you still have time to maintain this library? I've submitted a PR announcing that it needs maintainers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants