docs: describe defprocotol+ about potemkin HOT 9 CLOSED

👍🏻 PR?

from potemkin.

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

from potemkin.

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

from potemkin.

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)

from potemkin.

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.

from potemkin.

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 😄

from potemkin.

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! ❤️

from potemkin.

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.

from potemkin.

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

from potemkin.