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
I have observed that every single utility function that we write all depend on the verbose boolean flag that is passed from the app through to the exercise_utils (here).
This not only creates a really ugly dynamic of having to always include this parameter in every utility function, it also creates constraints on the design of these utility functions. For instance, a utility function that receives optional inputs will be constrained to have a signature of func(a, b, verbose, optA=, optB=) which isn't very nice to work with.
Something that I have done with the app is to load the verbose value once through the click.Context global object, and then reading from it from every other command. While we could make the same assumption here within the utility functions, the fact that they reside in a separate repository makes me feel like we might want to think twice about that.
There are two proposals for this:
Create multiple wrappers for each category of utility functions and wrapping them all into a super-wrapper: utility for instance. In doing so, we would access the various functions as such: utility.git.pull(). By initializing a single instance, we can store the verbose value once and then access it internally. However, the primary con for this approach is that it affects a lot of the existing surface area which isn't as ideal.
Make the assumption that these utility functions are always executed in the context of the app, so we read them directly from the supposed click.Context and remove the verbose flag entirely. The primary con here is that there may be a time where someone uses a utility function outside of the app which causes it to fail. But given that the assumed interface of the exercises repository is always through the app, this might be a minor concern only
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Based on git-mastery/exercises#123
I have observed that every single utility function that we write all depend on the
verboseboolean flag that is passed from theappthrough to theexercise_utils(here).This not only creates a really ugly dynamic of having to always include this parameter in every utility function, it also creates constraints on the design of these utility functions. For instance, a utility function that receives optional inputs will be constrained to have a signature of
func(a, b, verbose, optA=, optB=)which isn't very nice to work with.Something that I have done with the
appis to load theverbosevalue once through theclick.Contextglobal object, and then reading from it from every other command. While we could make the same assumption here within the utility functions, the fact that they reside in a separate repository makes me feel like we might want to think twice about that.There are two proposals for this:
utilityfor instance. In doing so, we would access the various functions as such:utility.git.pull(). By initializing a single instance, we can store theverbosevalue once and then access it internally. However, the primary con for this approach is that it affects a lot of the existing surface area which isn't as ideal.app, so we read them directly from the supposedclick.Contextand remove theverboseflag entirely. The primary con here is that there may be a time where someone uses a utility function outside of theappwhich causes it to fail. But given that the assumed interface of theexercisesrepository is always through theapp, this might be a minor concern onlyBeta Was this translation helpful? Give feedback.
All reactions