Sorry for jumping late inside the pool, but the topic has retained my
attention from day one.

As a developer of an IDE plugin (CounterClockWise for Eclipse), I'm very
interested in this effort.
Here are my ideas/questions/remarks:

- Finding a winning scenario for adoption is key. A perfect tool with no
users will be of no use
- Specifically, for broad adoption, one scenario I can see is that such
APIs are automatically delivered by library authors without changing any of
their habit. E.G. the result would be automatically downloaded to either
clojars or maven central as just an additional jar with a specific
classifier.
- To be even more specific, I think that this means that from start you
should plan to provide leiningen plugin, at the very least. And probably
maven (clojure-maven-plugin) and boot plugins as well. Go reach the users
where they are.
- Of course, from the point of view of an IDE, which already has the
tooling to get jars from maven repositories, it would not be difficult then
to get information from libraries, that could be used to help Users anytime
about the libraries they've chosen. No need to get a REPL open and get all
the project namespaces loaded. No need to reinvent another way to
statically parse all the project dependencies to get static analysis (at
least for the project dependencies).
- This would also enable providers of not open-source projects to deliver
the API - and not the source code -, and for this kind of scenario only
your solution will be of help.

If I remember well, when talking about this with Tom Faulhaber, the author
of Autodoc, several years ago (yeah, hammock time can sometimes be veeeeery
long ;-) ), he told me that everything was already there, in Autodoc, after
it had produced the HTML pages. But maybe not published in the final "HTML"
product. But definitely there, maybe even not just in memory, but as an
intermediary set of files to be transformed, on the filesystem.

Last point for today: I don't know how easy it could be done, but if the
tool could give most possible accurate guidance about which arguments of a
macro should be considered as symbols that will name locals inside the
macro body, that would be very cool ! Currently Cursive probably has a list
of macros for clojure core, and for most used clojure projects, with a way
to declare which argument will be a symbol usable as a local, etc.
Sooner or later, I'll have to do that for CCW also.
Unless a standard comes out from your project first, which would be great
:-)

HTH,

Laurent








2015-05-20 2:34 GMT+02:00 Richard Möhn <richard.mo...@posteo.de>:

> Just trying to bump this up a bit. "Coding" will start soon, so I'd be
> happy about some more input. Especially if you have further thoughts or
> wishes along the lines of
> https://groups.google.com/d/topic/clojure/E1oxVE4UMxQ/discussion.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Laurent Petit

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to