search

clj-commons / potemkin

some ideas which are almost good
577 stars 53 forks source link

docs: describe defprocotol+ #67

Closed lread closed 1 year ago

lread commented 2 years ago

Potemkin includes defprotocol+ but the README does not make mention of it.

A recent conversation on slack reminded me I moved from an inlined version of defprotocol+ to defprotocol when merging rewrite-clj v0 and rewrite-cljs v0 to create rewrite-clj v1.

At the time I, wrongly, assumed defprotocol+ was somehow related to performance. Maybe I was swayed by the definterface+ description mentioning "time and memory". I dunno.

@dpsutton kindly helped me to understand that defprotocol+ is about REPL reload friendliness and deals with this kind of scenario.

I'd be happy to add a few words in the README about this with the sentiment that it is something that would have helped me understand, so it will probably help others.

KingMob commented 1 year ago

👍🏻 PR?

lread commented 1 year ago

Looks like I did one! #69 I was hoping somebody could review it for correctness/completeness before merging.

lread commented 1 year ago

@KingMob are your comments implying that you are becoming a maintainer for this project? :crossed_fingers:

KingMob commented 1 year ago

Well, sort of... Would you like to maintain it?

I originally just wanted to maintain Manifold, which I was using heavily at the time. Then we needed to make some changes to Aleph, and I started maintaining that, too. Ditto for gloss, byte-streams, byte-transforms, etc. All of Tellman's old libraries.

However, I'm personally reluctant to do too much to potemkin. Mostly because it's in widespread use, especially import-vars. For now, I'm mostly interested in updating docs, adding kondo support where possible, and maybe deprecating things that no longer make sense (like clj-tuple, fast-memoize, etc)

lread commented 1 year ago

Well, sort of... Would you like to maintain it?

No, I had a falling out with import-vars and am not excited to spend more time with it. 😄

I originally just wanted to maintain Manifold, which I was using heavily at the time. Then we needed to make some changes to Aleph, and I started maintaining that, too. Ditto for gloss, byte-streams, byte-transforms, etc. All of Tellman's old libraries.

I hear ya, In the clj-commons family, I am a maintainer on rewrite-clj, etaoin, clj-yaml, clj-http-lite, and pomegranate.

However, I'm personally reluctant to do too much to potemkin. Mostly because it's in widespread use, especially import-vars. For now, I'm mostly interested in updating docs, adding kondo support where possible, and maybe deprecating things that no longer make sense (like clj-tuple, fast-memoize, etc)

That makes sense to me and is the approach I took with pomegranate. Primarily, I've taken on:

  1. dealing with all outstanding issues & PRs, and doing my best to respond to any new ones
  2. bumping deps to deal with CVEs (and adding in automated scanning)
  3. adding automated CI deploy scripts
  4. trying to grok the library so I can better support it
  5. updating docs and docstrings (this greatly helped with 4).

I don't expect much work on pomegranate after this initial work. From time to time I expect to deal with 1 and 2.

KingMob commented 1 year ago

Heh, I understand. A lot of people have burned by import-vars, which is a shame, because it fits a real need, and makes it easy to reorganize behind the scenes. I think "complect" is a silly word, so let's just say, the default clj setup intertwines file layout with API design.

Luckily, potemkin is updated rarely, so I don't need to worry about automating builds, and it has almost no deps, so I don't need to worry much about CVEs. I do think I need to run some performance analyses to know what to deprecate, though. Still, it's pretty low-priority; it seems like import-vars is what 99% of people want from potemkin 😄

lread commented 1 year ago

I'm not offended by the idea of importing vars, if Clojure core had such a feature I would likely use it. But because importing vars is not a core feature, tooling support is hit and miss, which for me, makes it impractical and too costly to use.

Anyhoo, it is nice to have someone looking at PRs and issues for potemkin, thanks for that! :heart:

KingMob commented 1 year ago

I'm not offended by the idea of importing vars, if Clojure core had such a feature I would likely use it.

Yeah. Shame it's effectively impossible to change core. There are real limits to what you can do with an outside library.

lread commented 1 year ago

The arguments for and against the concept seem reasonable to me. I'm fine with going with the Clojure core team flow here.