Extend andika builtin
#82
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cornform to the go coding style by using the `gofmt` tool to format the code. This makes the code more "readable" and "maintanable". Signed-off-by: Gekko Wrld <[email protected]>
The builtins are now in their own package. This is to ensure extendable functions as opposed to the previous method which they were in a "fixed" array. Accessing the functions still uses an array as before. This may be fixed to use a better way of accesing the builtins but that will be done later. Signed-off-by: Gekko Wrld <[email protected]>
Now the basic code that does basic find and replace has been finalized. The following have yet to be implemented: - No type checks are done, anything is printed. - Only two types are supported - No error is raised on incorrect values. Other buitins have been moved to another file to create room to extend the `Andika` function. This is intended to other builtins. Signed-off-by: Gekko Wrld <[email protected]>
Signed-off-by: Gekko Wrld <[email protected]>
Now types are checked before appending to the 'new string'. The '%' is truncated before being printed even if the syntax turns out to be wrong. An array is used to keep the type and subsequently checked against. This is ineffective speed and perfomance wise. A better solution _may be found_ in the future though. >> No error handling yet Signed-off-by: Gekko Wrld <[email protected]>
Now the code can handle gracefully: - boolean - arrays Error handling has been enhanced to acceptable level (whatever that is). Type mismatch is now reported appropriately. If there is a mismatch in format specifiers to the actual arguments, then an error is raised. This only happens if the format specifiers are more than the passed arguments. This doesn't apply the other way round. This is consistent with how C handles this same situation in lax situation (not tested in strict and golang though). Changed the allowed specifiers to match their swahili names, making it easier for swahili learners to pick up the specifiers. This can be reverted though as it is mostly convention and not hard rules. Code comments have been included to try and break down the code logic. Repetetive part(s) have only been explained once. This is to help maintainers and developers skim through the logic with the help of the comments and understand it. I know that this doensn't substitute clean readable code but it sure does help. Format specifiers: - %n -> Nambari - %t -> Tungo (ama neno) - %b -> Buliani (kweli, sikweli) - %s -> Safu (ama orodha) Signed-off-by: Gekko Wrld <[email protected]>
Previous implementation used case to match the format to its implementation. Now it uses a map to do the matching. This method has a couple of upsides: - Now Flags can be handled easily - The formats supported can be changed without logic change - The 'main' function doesn't grow long with more implementations - Each format can be treated as its own entity Downsides: - More time is spent on matching than previous implementation. - More boiler plate code (not that much but adds up) - `if` is slower than `case` (in some cases :) though) Signed-off-by: Gekko Wrld <[email protected]>
Now flags infrastructure has been set up fully.
Addition of flags can be done now in few simple modifications.
For now only the following flags have been implemented:
- '+': Add a preceding '+' in integer values.
- '.': Add a predefined number of zeroes to float (DESIMALI)
- '!': Convert to uppercase the string passed (should be removed in the future).
The above implementated flags are just for demonstration of the flags
feature and not a concreate impelementation.
'%d' Have been added to the list of supported flags.
The flags represents "DESIMALI" type (e.g 2.4)
Error reporting is still not at par but good enough to nudge the user
in the right direction, but %.12 for example doesn't report any error.
The code still doesn't actually follow the DRY principle.
A lot of code is repeated.
Not sure if this is the biggest concern as of now.
Example usage as of now:
>>> andika('Habari %!t\n', 'nuru')
Habari NURU
>>> andika('%+.5d\n', 2.3)
+2.30000
If the flag is not known they it is silently ignored (the same as in golang (partly though)).
If the syntax is messed up, then undefined there will be undefied behaviour:
e.g:
>>> andika('%#.2_3d\n', 2.4)
2.40
This may or may not be the desired behaviour but the best that can be done (as of now).
NOTE:
Now andika() doesn't add an extra '\n' to the end of strings.
This **may** break the previous implementations.
This only happens if the first argument is a string, else the previous
implementation still aplies.
Signed-off-by: Gekko Wrld <[email protected]>
|
Added: |
The Functions have been simplified.
A loop over slices have been converted into a map.
Flags are now resolved and the results passed to the functions
directly.
This reduces the boiler plate that was there before.
Conversion to int64 then to int has been simplified to just
an int.
An error is returned if the string ends before any format
specifier is found e.g
>>> andika('%4', 3.4)
Kosa: Siwezi kupata fomati inayofaa
The 'substitution' array `must` be equal to the 'real' array
>>> andika('Habari %t uko na miaka %n\n', 'Hana')
Kosa: Safu mbadala ni chini ya safu halisi
>>> andika('Habari %t uko na miaka %n\n', 'Hana', 21, ['a'])
Kosa: Safu halisi ni chini ya safu mbadala
Signed-off-by: Gekko Wrld <[email protected]>
|
These are my thoughts:
|
|
I did also test:
|
It tries to implement as explained in #81 c-style formatting. The only difference being the 'characters' used. I used characters as used in
I agree, most of the 'changes' are really the ones that were made by running |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
nildereference in expressionsgofmtto format the go codeFixes: #81
What hasn't been done:
Check types before doing the substitution.
Error checks.