[Feature request] Formalize/Make-explicit the data structures used throughout org-fc

[cashpw]

I had a hard time following the code the first time I read through because the representation of a card/position/etc isn't immediately clear. I expected to find something like org-fc-review-session or a cl-defstruct for each of the nouns used in org-fc (e.g. position, card, index). How do you feel about adding more defclass definitions (e.g. org-fc-position).

Based on what I can tell, those structures could look like:

`org-fc-card`

(defclass org-fc-card ()
  ((created
    :initform nil
    :initarg :created)
   (filetitle
    :initform nil
    :initarg :filetitle)
   (tags
    :initform nil
    :initarg :tags)
   (id
    :initform nil
    :initarg :id)
   (inherited-tags
    :initform nil
    :initarg :inherited-tags)
   (local-tags
    :initform nil
    :initarg :local-tags)
   (path
    :initform nil
    :initarg :path)
   (positions
    ;; List of `org-fc-positions'
    :initform nil
    :initarg :positions)
   (suspended
    :initform nil
    :initarg :suspended)
   (title
    :initform nil
    :initarg :title)
   (type
    :initform nil
    :initarg :type)))

`org-fc-position`

(defclass org-fc-position ()
  ((box
    :initform nil
    :initarg :box)
   (card
    ;; `org-fc-card'
    :initform nil
    :initarg :card)
   (due
    :initform nil
    :initarg :due)
   (ease
    :initform nil
    :initarg :ease)
   (interval
    :initform nil
    :initarg :interval)
   (pos
    :initform nil
    :initarg :pos))
  "Represents a single position.")

`org-fc-review-session-rating`

(defclass org-fc-review-session-rating ()
  ((total
    :intiform 0
    :initarg :total)
   (again
    :intiform 0
    :initarg :again)
   (hard
    :intiform 0
    :initarg :hard)
   (good
    :intiform 0
    :initarg :good)
   (easy
    :intiform 0
    :initarg :easy)))

[l3kn]

I agree that this would help with the readability of the code.

A few years ago I thought about switching the card types to use eieio,
so common code could be shared between cards of different types.
In the case of your defclass org-fc-card with a :type field,
the next logical step would be to skip that :type field and use a subclass for each card type.

I can't remember why I decided against it at that time, here it seems like it could lead to a number of invasive changes, exchanging the learning curve of figuring out which element of a list is which to the learning curve of understanding the details of eieio.

cl-defstruct seems closer to a style already used in some places in org-fc,
a combination of a constructor function that wraps it's arguments in a list
and a set of getter-functions, just automatically defined by a macro.

[l3kn]

Looks like org-fc-review.el already uses defclass
while other files using different styles of wrapper complex data into lists or plists.

In this case my argument about the added learning curve is invalid,
we could just begin with a limited set of eieio functionality and later extend that as we see fit.

[cashpw]

Thank you for merging #102 and #103 into develop! Do you have a timeline or testing plan for graduating develop into main?