-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Organize the code better #4
Comments
This makes the BitArray implementation encapsulated, and all operations over it are made via procedures. Issue: #4
As can be seen in the previous commit, the decided approach to follow is to encapsulate the |
After the last commit these are the results of the benchmark: Some noticeable 5ms (another 1ms was added, strangely, by 05033b5). |
I have decided that I'm going to remove the encapsulations made to both Why? Well, I just remembered what I most hate about encapsulation: boilerplate and a huge amount of calls to do stuff. Maybe encapsulation is good to use when providing objects to a user, but in the actual code this is not done (well, you can touch the fields of the DrawedQRCode given from the main API, but that may be changed later), so there is actually no need to have all these procedures for the sake of "controlling the setting and getting of values". |
The issues mentioned about templating has been removed and they are now located in their respective module |
There are some issues with the actual code organization, mainly about the usage of templates, for example in
EncodedQRCode.nim
, where there are some templates used to writemyEncodedQRCode[]
which maybe should be just written asmyEncodedQRCode.data[]
, and this implies that theencodedData
field should be renamed todata
.Why though?
Well, I think this actually adds more complexity than it helps to understand the code, it may reduce the amount of code written, but at the expense of readability.
Then, why having these
[]
templates for BitArray?Because a BitArray, as said in the docs (haven't pushed those atm) should be treated as a regular sequence but with the difference that it has some specialized procedures, those being both
add
andnextByte
.Also
unsafeAdd
andunsafeDelete
should be moved toBitArray.nim
, maybe some of the fields of objects likeBitArray
orDrawing
should be private to their module, and only accessible via getter procedures if actually needed.The text was updated successfully, but these errors were encountered: