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

Limit use of non-primitive types throughout the API #407

Closed
dcousens opened this issue May 20, 2015 · 7 comments
Closed

Limit use of non-primitive types throughout the API #407

dcousens opened this issue May 20, 2015 · 7 comments
Assignees
Milestone

Comments

@dcousens
Copy link
Contributor

As a result of the discussion in #359, the aim will be to limit the use of non primitives in the API.

Buffer is considered a primitive in this case, and is therefore acceptable.

@dcousens dcousens added the todo label May 20, 2015
@dcousens dcousens self-assigned this May 20, 2015
@dcousens dcousens added this to the 2.0.0 milestone May 20, 2015
@dcousens
Copy link
Contributor Author

Wherever the API changes, warnings will need to be added to 1.5.x.

@dcousens
Copy link
Contributor Author

dcousens commented Jul 7, 2015

Best I can tell, the only non-primitive constructor that we have is in function ECPair (d, Q, options).

@dcousens
Copy link
Contributor Author

dcousens commented Aug 7, 2015

I didn't realise before, but Script is a major component which could be simplified down to a Buffer for interop.

With modules like https://github.com/bitcoinjs/bip69 coming up, the ability to reduce this part of the API would be asimilar to the changes made to Address.

And therefore highly beneficial.

@dcousens
Copy link
Contributor Author

dcousens commented Sep 26, 2016

For the record, as per #407 (comment), script was transitioned to a Buffer in 2.0.0.
As was a Address to address.

Non-POD data types that still exist are basically limited to ECDSA system... and that's it?
I don't think we'll be able to break down ECPair in any way useful.

@dcousens
Copy link
Contributor Author

Related 0030854

@dcousens
Copy link
Contributor Author

dcousens commented Mar 19, 2017

We really want to avoid the use of bigi in the API for the next version, IMHO (or any equivalent big int)

@dcousens
Copy link
Contributor Author

dcousens commented Sep 26, 2017

Closing in favour of #508

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

No branches or pull requests

1 participant