Skip to content

Very crude initial support for BigInt (if present)#252

Open
CyDragon80 wants to merge 3 commits intosidorares:masterfrom
CyDragon80:master
Open

Very crude initial support for BigInt (if present)#252
CyDragon80 wants to merge 3 commits intosidorares:masterfrom
CyDragon80:master

Conversation

@CyDragon80
Copy link

Inspired by #248

This an initial attempt to allow the use of BigInt (if it is available) without breaking backwards compatibility. At present it uses strings to convert between Long.js and BigInt. At some point that could probably be replaced with more efficient mathematic operations or some kind of BigInt functionality, but this is a start at least. (Perhaps in future, it will be primarily BigInt with Long.js as a fallback? Guess time will tell.)

Not sure if there should be an option to always unmarshall to BigInt, or if automatically flipping from number to BigInt when needed is fine.

@CyDragon80
Copy link
Author

On further thought, it would probably be more consistent and deterministic to have an option for 64 bit return types that is an enum of 'number', 'bigint', and 'longjs' (perhaps deprecate ReturnLongjs). The automagic flipping between number and bigint on certain conditions could potentially be confusing. Thoughts?

@CyDragon80
Copy link
Author

CyDragon80 commented Nov 24, 2018

Not seeing Travis results, but I did test on Node 6 and 10. BigInt specific tests only run on 10+ as BigInt is not defined previous to that and are automatically skipped.

CyDragon80 referenced this pull request in dbusjs/node-dbus-next Feb 6, 2019
(Breaking change)

Always use BigInt to represent dbus int64 and uint64 types.

Remove Long.js dependency.
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

Successfully merging this pull request may close these issues.

1 participant