String labels -> keywords in API responses #7

New Issue

Open

opened 2022-01-17 10:05:03 -06:00 by BnMcGn · 0 comments

BnMcGn commented

2022-01-17 10:05:03 -06:00

(Migrated from github.com)

Calls to the IPFS API currently return alists that are keyed with strings. It would be nice if the alists used keywords instead.

This is fairly easy to implement. A function something like this:

(defun process-object-key (item)
  (alexandria:make-keyword (string-upcase (kebab:to-lisp-case item))))

And then the yason:parse function can be called with :object-key-fn #'process-object-key

The benefits are:

No need to add :test #'equal to all of the assoc calls.
Keyword lookups are faster than string comparisons.
Keywords are a Common Lisp convention for keyed storage.

The big downside is that it breaks the API. I can easily write up a patch to change things in cl-ipfs-api2 itself, but I don't want to make a mess for other users.

If necessary, I could make keywords optional. Let me know what you think.

Calls to the IPFS API currently return alists that are keyed with strings. It would be nice if the alists used keywords instead. This is fairly easy to implement. A function something like this: (defun process-object-key (item) (alexandria:make-keyword (string-upcase (kebab:to-lisp-case item)))) And then the yason:parse function can be called with :object-key-fn #'process-object-key The benefits are: - No need to add :test #'equal to all of the assoc calls. - Keyword lookups are faster than string comparisons. - Keywords are a Common Lisp convention for keyed storage. The big downside is that it breaks the API. I can easily write up a patch to change things in cl-ipfs-api2 itself, but I don't want to make a mess for other users. If necessary, I could make keywords optional. Let me know what you think.