You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This one comes out of discussion with @dbaeumer on the base-level type implementations.
Currently we implement flags as an object of bools, the suggestion would be switch to implementing all flags as BigInt values.
For users to be able to interpret and create flags, they would need to explicitly import from the flag type itself in JavaScript, something like:
import{MyFlags,fnReturningFlags,fnTakingFlags}from'lib';constflagValue=fnReturningFlags();typeofflagValue==='bigint';// trueif(flagValue&MyFlags.ValueA){// we have ValueA true}fnTakingFlags(MyFlags.ValueA|MyFlags.ValueB);
BigInts have full support for binary operations in JS, so the above works out okay. In addition BigInts have unlimited length so will be fully compatible with arbitrary flags.
There would be a slight savings over allocating full JS objects for all values, but the major benefit would be simplicity from a user interface perspective, where creating bags of bools can feel unintuitive at the moment (especially when it is currently ambiguous that falsy values are optional in inputs).
I'm bringing this up now, because if made it would be the last major breaking change in jco before we stabilize preview2, so seems a good time to think about making this change now.
The text was updated successfully, but these errors were encountered:
This one comes out of discussion with @dbaeumer on the base-level type implementations.
Currently we implement flags as an object of bools, the suggestion would be switch to implementing all flags as BigInt values.
For users to be able to interpret and create flags, they would need to explicitly import from the flag type itself in JavaScript, something like:
BigInts have full support for binary operations in JS, so the above works out okay. In addition BigInts have unlimited length so will be fully compatible with arbitrary flags.
There would be a slight savings over allocating full JS objects for all values, but the major benefit would be simplicity from a user interface perspective, where creating bags of bools can feel unintuitive at the moment (especially when it is currently ambiguous that falsy values are optional in inputs).
I'm bringing this up now, because if made it would be the last major breaking change in jco before we stabilize preview2, so seems a good time to think about making this change now.
The text was updated successfully, but these errors were encountered: