If your library is intended specifically to provide the ability to datafy/nav java.time objects then it is something optional that users can choose to opt into.
The section you meant to link to https://clojure.org/reference/protocols#_guidelines_for_extension says: “To minimize conflicts, consider these guidelines” So they’re a) guidelines and b) just given as a caution to minimize conflicts. There are libraries out there already that exist specifically to give users the option to extend protocols from one library (such as clojure.java.jdbc or next.jdbc) to Java types to provide customized behavior, above and beyond the “base versions for common targets” mentioned in that section provided by the original library. I see benefit in libraries that extend Clojure’s datafy/nav to new domains as a narrow purpose that users can opt into. I see much less benefit in providing the same protocols and function names that core already includes, targeted to new types, in an isolated way such as this. Perhaps that is because I’m already using datafy/nav and I find their utility is enhanced by being extended to other Java types? Yes, if multiple people write multiple libraries A, B, C that extend datafy/nav to java.time types and then other libraries X, Y, Z start pulling in those extenders, consumers of X, Y, Z can be in trouble. Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: dimitris Sent: Thursday, January 30, 2020 9:58 AM To: clojure@googlegroups.com Subject: Re: Feedback on datafy/nav project Well, the official Clojure guidelines are to NOT extend protocols, unless you own either the protocol of the type(s) [1]. In particular these lines: If you are a library developer, you should not extend if you own neither the protocol nor the target. You should take particular care when extending protocols included with Clojure itself. Kind regards, Dimitris [1]: https://clojure.org/reference/protocols#_extend_via_metadata On 30/01/2020 17:50, Sean Corfield wrote: Is there a reason you’ve mirrored those protocols/implementations rather than just use Clojure’s built-in versions? As it stands, your library wouldn’t work with other tooling that builds on Clojure’s datafy/nav (REBL, for example). Sean Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: dimitris Sent: Thursday, January 30, 2020 9:05 AM To: Clojure Subject: Feedback on datafy/nav project Hi folks, I'm looking for honest and constructive feedback on [1] - not so much about the actual implementation (even though these are welcome too), but rather about the general idea of basing everything on top of (mirrored versions) `datafy` and `nav` (in this way). There is a TL;DR section at the very bottom that describes the approach in 4 short sentences. Many thanks in advance, Dimitris [1]: https://github.com/jimpil/jedi-time -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/d0db9e09-6419-2e13-3a0b-9bacf2bbf4fd%40gmail.com. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/5e331755.1c69fb81.ff1ad.21cf%40mx.google.com. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/3caceeee-a3e9-4b74-bb86-870d3012fa5e%40gmail.com. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/5e33818b.1c69fb81.42724.5d42%40mx.google.com.
