<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
<title>Clojure Q&amp;A - Recent questions tagged doc</title>
<link>https://ask.clojure.org/index.php/tag/doc</link>
<description></description>
<item>
<title>It's difficult to figure out options I can pass to slurp function.</title>
<link>https://ask.clojure.org/index.php/14975/its-difficult-to-figure-out-options-can-pass-slurp-function</link>
<description>&lt;p&gt;&lt;code&gt;(doc slurp)&lt;/code&gt; says&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;clojure.core/slurp&lt;br&gt;
([f &amp;amp; opts])&lt;br&gt;
  Opens a reader on f and reads all its contents, returning a string.&lt;br&gt;
  See clojure.java.io/reader for a complete list of supported arguments.&lt;/p&gt;
&lt;p&gt;(doc clojure.java.io/reader) says&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;clojure.java.io/reader&lt;br&gt;
([x &amp;amp; opts])&lt;br&gt;
  Attempts to coerce its argument into an open java.io.Reader.&lt;br&gt;
   Default implementations always return a java.io.BufferedReader.&lt;/p&gt;
&lt;p&gt;   Default implementations are provided for Reader, BufferedReader,&lt;br&gt;
   InputStream, File, URI, URL, Socket, byte arrays, character arrays,&lt;br&gt;
   and String.&lt;/p&gt;
&lt;p&gt;   If argument is a String, it tries to resolve it first as a URI, then&lt;br&gt;
   as a local file name.  URIs with a 'file' protocol are converted to&lt;br&gt;
   local file names.&lt;/p&gt;
&lt;p&gt;   Should be used inside with-open to ensure the Reader is properly&lt;br&gt;
   closed.&lt;/p&gt;
&lt;p&gt;I read the source code, and I was confused even more.&lt;/p&gt;
</description>
<category>Docs</category>
<guid isPermaLink="true">https://ask.clojure.org/index.php/14975/its-difficult-to-figure-out-options-can-pass-slurp-function</guid>
<pubDate>Fri, 27 Feb 2026 06:41:39 +0000</pubDate>
</item>
<item>
<title>Can doc and jdoc be refactored to a common protocol while it's still early?</title>
<link>https://ask.clojure.org/index.php/14734/can-doc-and-jdoc-refactored-common-protocol-while-still-early</link>
<description>&lt;p&gt;A fresh clojure library clojure.java.doc introduces some nice functions for querying javadoc.&lt;br&gt;
It all seems nice and useful, I really can't complain (nor this is high priority to me since Javadoc is usually so verbose that I would probably continue to read it in the Web browser unless I discover use cases where REPL access is more practical to me).&lt;/p&gt;
&lt;p&gt;However, one thing that struck my mind, and I had to ask is this: why introduce new functions, such as jdoc? Wouldn't it be more convenient to introduce a protocol (say, doc) which could then be extended to support&lt;br&gt;
1. original Clojure doc&lt;br&gt;
2. Javadoc&lt;br&gt;
3. some sort of javascript doc, if that exists&lt;br&gt;
4. C# doc&lt;br&gt;
5. Native libraries doc, etc.&lt;/p&gt;
&lt;p&gt;I understand that doc is a part of Clojure core, which you avoid changing at any costs, but this protocol wouldn't have to touch it.&lt;/p&gt;
&lt;p&gt;It could simply be a &quot;replacement&quot; from the new namespace, which would have one implementation that invokes doc, but also be open to other implementations, such as jdoc.&lt;/p&gt;
&lt;p&gt;And I understand that for Clojure core it's an absolute priority to not even change a formatting of the source code unless it's absolutely necessary, to keep very detailed compilation behavior or whatnot. It's a choice you made, it has its traidoffs, you chose those, and that's it. But, are those tradeoffs the same for namespaces such as clojure.repl and functions such as doc?&lt;/p&gt;
</description>
<category>java.doc</category>
<guid isPermaLink="true">https://ask.clojure.org/index.php/14734/can-doc-and-jdoc-refactored-common-protocol-while-still-early</guid>
<pubDate>Tue, 28 Oct 2025 11:41:48 +0000</pubDate>
</item>
</channel>
</rss>