Closed alovak closed 1 year ago
It sounds like AutoExpand: false
is the current behavior so that should be the default. Changing this into an auto-expanding bitmap (by default) will break existing code.
LGTM the approach is good
my advice is
@adamdecaf our current behaviour is AutoExpand: true
that's why I had to introduce option that is false by default (negative naming).
@mfdeveloper508 thanks for the suggestions
I tried to not break anything. Now integration will be broken only if Length
is different from 8. If it's not, then new version of the package will not require any changes from you.
I like your proposal, but I'm afraid as it's a not backward compatible change, I would vote for DisableAutoExpand
.
,
remove DisableAutoExpand option AutoExpand is active if there isn't any length setting AutoExpand is inactive if there is any length setting ^^ this will force people to make updates to their systems as the default use case is auto expand and I believe most of the time
Lenght
is specified.
I'm also not aware of cases with auto-expanding bitmaps of length different than 8. But maybe there are such cases?
Thanks for making it backwards compatible.
What
DisableAutoExpand
(bool) to the field spec. Used by thefield.Bitmap
field.Bitmap
will be just a fixed bitmapDisableAutoExpand
to true)Example of how to create fixed bitmap:
Why
182
P.S. Note, for most card brands, the default single bitmap size is 8 bytes (64 bits). Because of the previous implementation, the Length parameter was ignored and instead underlying storage for the 3 (max allowed) bitmaps was used. For all operations, it calculated the number of bitmaps based on the bits set. So, if for auto-expanding bitmaps you use 16 or something else, then bitmap will be expanded by 16 bytes for new bitmaps. That's not what you want. Just change from 16 to 8.