Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add classes for cards and positions #102

Merged
merged 1 commit into from Oct 4, 2022
Merged

Conversation

cashpw
Copy link
Contributor

@cashpw cashpw commented Sep 27, 2022

Resolves #94

@cashpw cashpw force-pushed the feat/classes branch 2 times, most recently from c249041 to ac5340b Compare October 3, 2022 18:11
:initform nil
:initarg :positions
:type list
:documentation "The `org-fc-position's for this card.")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how to specify a type that is a list of another defclass-type. I found some reference code which had:

(defclass custom-type ()
  ...)

(defclass foo ()
  ...
  (bar
  :initform nil
  :initarg :bar
  :type list
  :custom (repeat (object :objecttype custom-type))
  ...)

However, Emacs didn't throw any errors when I set the value to a list of non-custom-types.

(let ((-compare-fn (lambda (a b)
(equal (oref (oref a card) id)
(oref (oref b card) id)))))
(-distinct positions)))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found the use of -distinct to be more legible than the alternative. I'm open to suggestions as this uses dash in contrast to the existing implementation.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been thinking about this, my original motivation was to avoid adding an dependency
but if you'd like to use dash.el I'm ok with that.

Another question is whether we want to use the anaphoric functions, too.
Initially that would make it harder to understand the code but the same argument can be made
against the use of cl-loop. It should be fine if we note it somewhere in the documentation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another question is whether we want to use the anaphoric functions, too.

I don't think there is a anaphoric counterpart for -distinct/-uniq.

[...] the same argument can be made against the use of cl-loop.

Would you like me to swap the cl-loop out for a --filter?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't take what I wrote as a critique of your code.

The point I'm trying to make is that the increase in expressiveness of any library or complex macro (cl-loop, anaphoric dash.el) comes at the cost of an initial hurdle to understanding the code for new developers.

That's ok as long as there's kind of “before jumping into the code, check out these docs” disclaimer,
and as long as we're in agreement on which (all?) features we'll use.

I'm fine with adding dash and using all the features it provides,
e.g. avoiding “wrapper-lambdas” when possible.

Not sure about how existing code should be handled,
refactoring it just to fit the newer style seems like a lot of effort
but we can just fix it as we come across it.

@l3kn l3kn changed the base branch from main to develop October 4, 2022 14:54
@l3kn l3kn merged commit 4746e1b into l3kn:develop Oct 4, 2022
@l3kn
Copy link
Owner

l3kn commented Oct 4, 2022

I've merged this is into a new “develop” branch for now
so it's easier for me to test it out and make adjustments.

@cashpw
Copy link
Contributor Author

cashpw commented Oct 4, 2022

Looks like I missed one: #103

@l3kn
Copy link
Owner

l3kn commented Nov 30, 2022

This got a bit confusing because I merged this without properly looking at it.

Due to the licensing and formatting problems I mentioned in #106,
I've removed the code for now.

I still think this is a useful refactoring but we'll need to make sure it fits in with the rest of org-fc
and doesn't conflict with non-shuffled review I'm working on.

@cashpw cashpw mentioned this pull request Dec 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

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