For this exercise, we will extend the calculator's operators to support the following:
**%//&|^⭐⭐
This is a straight forward exercise to extend the existing operator set with new functionality.
This assignment presents a challenge to the extensibility of the operator code. It can be used as a talking point to discuss the abstractions that were applied for handling operations. For Irena's submission, it would be worth asking how this could be implemented without using an if/else conditional spanning all 10 operators. This could segue into a more general discussion of different design directions that could be taken and how. It is also helpful to discuss how this could be unit tested.
For this exercise, we will extend the calculator input set to support the following:
πeγδ∞⭐⭐⭐
This is a variation on the operator extension exercise and serves to test the extensibility of the operand code.
For Irena's submission, most of the line processing logic is handled via catching exceptions. The code currently attempts to cast all values to a float. It assumes an operator if the cast fails.
This exercise might present a challenge to simple float casting and ideally would tease out conversation on how to better encapsulate number parsing and isolate that behavior from operator parsing. It also would be worthwhile to ask about how this new behavior would be unit tested.
For this exercise, we will extend the calculator to support the following unary operators:
!loglnWhen no additional operator is given, these operators will consume that last entered number and replace its value in the stack with the result.
2 3 ! +
> 8
4 6 log
> 4 0.77815125038
+
> 4.77815125038
⭐⭐⭐
This can exercise the operator code, operand code, and the stack implementation all at once depending on how it is implemented.
For Irena's submission, this change will increase cyclomatic complexity across the board. Using the current architectural style, it will require an additional constant to track unary operators. An additional if/else circuit will be needed to perform unary-specific operations. It will also require a repeat if/elif/elif pattern to implement the behavior for each unary unless some other architectural approach is taken. If we start going down this path, it will be useful to have a conversation about other ways to tackle the problem. This will also increase the difficulty of unit testing and might foster good conversation on the topic.
For this exercise, we will extend the calculator to differentiate the file mode from the terminal mode.
In "File mode", we will not quit on empty line, Q, or q and we will not print the stack result until the application has terminated.
⭐⭐⭐
This change largely entails forking the behavior of the application.
For Irena's submission, this change will ideally require dependency injection or it will not have the ability to be unit tested. Using the existing architectural style will increase the complexity of the application across the board and require the same procedural code to handle and check for different interfaces. For Irena's submission, this change will ideally necessitate dependency injection or it will not have the ability to be unit tested.
Do a research spike, and create a definition for Samples separately. And then test it through the LSU linking.
What's left?
resolves/spreadsheet.ex#spreadsheets as is but it might need to be refactored to search on the data inside.filterConfig.ts on the map at the top should be the easiest way to extend it.Menu.StackableIf you think this note resonated, be it positive or negative, send me a direct message on Twitter or an email and we can talk.