Class structure

[Kamik423]

As discussed in #7 it would make a lot of sense to shift cutie to a class structure to allow for overall customizability. This is a modified and updated version of the last post in there:

---

My reasoning for not wrapping it in a class was that the module should be very straightforward to use. I want the user to be able to call the functions directly without having to create a class instance first. I do not think that most users will really want to customize a lot. The strength of this module lies in its was of use, like prompting a yes or no question in a single straightforward line of human readable python.

My suggestion:

Option 1

• Add a class CutieConfiguration(ABC) which implements the functions but has abstract properties for keys and prefix strings etc. This is for users who want to customize every single bit without building on top of the default.
• Have a class DefaultCutieConfiguration(CutieConfiguration) wich contains the default key maps and prefixes (like [+]) for users who only want to tweak details
• Keep the current functions but strip out the implementation (which is in CutieConfiguration). When they get called they create a DefaultCutieConfiguration object and call its function. This keeps it simplest for users not seeking to customize anything.

Maybe CutieConfiguration and DefaultCutieConfiguration should be in the same class, I just think it is cleaner having those two separated.

Option 2

• It would also make sense to have a class per function, which have a run method (or so). I have a few reasons for this:
  • It would (like the CutieConfiguration from Option 1) reduce the amount of arguments being passed to a function.
  • Things like prefixes could be put into their own function, so there could be different prefixes for each line. Implementing this is unfeasible in the current structure. Example:

     1.  Foo
    [2.] Bar
     3.  Foobar
    

  • Unlike in the CutieConfiguration when just creating (for example) a custom select it would not contain configuration information for prompt_yes_or_no.
  • It would make it quite simple to use a modified version of a prompt multiple times.
  • HOWEVER there would have to be a separate way of storing key information. I can spontaneously come up with two solutions:
    • Using inner (nested) classes:

      class CutieConfiguration:
          class Keys:
              up: List[str] = [readchar.key.UP, 'k']
              ...
      
           class Select:
              def prefix(self, line: int, is_selected: bool) -> str:
                  return '[x]' if is_selected else '[ ]'
      
              def run(self) -> int:
                  ...
      
              ...

    • Or referencing a Configuration object from each Function.
  • Once again I'd leave the currently existing functions in place, but have them instantiate a preset default object to keep simple minimal cases.

---

I prefer option 2.

What do you think? Is there a better way or anything I am missing?