I apologize if this has been brought up before... But, where does the doc string on the `my-test' defn below reside.
If not, should I be able to defn with the doc string out of place without first passing a keyword?
I'm sure I'm missing something....
Maybe I should re address the issue in a different way; outside of
`meta' what other way is there to do a *visual* check/comparison to
test if two otherwise identical and/or nearly identical symbols
contain identical slot values?
In the case where the `doc' string (disregarding whether it is
actually a doc string or not) is placed after the param how does one
catch this (mis)placement when examining the `meta' on the symbol
returns nil?
You are not "passing a non-empty string", you are including a String
as part of a function body. You can include any legal Clojure form in
a function body.
So for example:
(defn foo [] 1 2 3 4 5)
-> #'user/foo
(foo)
-> 5
You could ask "Where did the 1, 2, 3, and 4" go? They were evaluated,
and foo then returned the result of the final expression 5.
Many languages work this way. In Ruby:
def foo
"evaluted and lost"
"return value"
end
Cheers,
Stuart
Am 04.12.2008 um 18:30 schrieb Mon Key:
> It looks like I was getting turned around by the implicit do (and by
> my preconceptions coming from other Lisps where the docstring likes to
> sit behind the arglist)
This doesn't work well with Clojure, because you can have
multiple argument vectors:
(defn foo
"docstring here"
([x] (do-something-with-one-arg x))
([x y] (we-can-also-do-two x y)))
Behind which arglist should we put the docstring. ;)
>> Many languages work this way. In Ruby:
> Some don't :)
But Lisp does. (Or at least Scheme does. Can't tell for CL.)
> So, it would have been safer to assume Ruby like behaviour :)
It's never safe to assume. It's only safe to know. So
good that you ask here on the list. :)
Sincerely
Meikel
Actually, I think each arity overload of a function deserves to be
independently documentable, just as each overload of a method name in a
Java class would be.
It would seem to be a syntactically upward-compatible change to allow a
doc-string before each overload's argument vector (inside the paren).
The details of what (doc ...) would present in such cases would have to
be decided and, perhaps more significantly, the way the metadata was
structured would have to be revamped, and that may entail non-
backward-compatible changes (to any code that examines the metadata on
Vars that hold functions).
And am I mistaken in my reading of the API docs for (defmulti ...) and
(defmethod ...) or is there no accommodation in either for doc-strings?
Surely that's not the case, right?
> ...
>
> Sincerely
> Meikel
Randall Schulz
Nope, that's the norm :)
- J.
Why all the circumlocutions to bring a multimethod up to the level of
documentation support of a plain function?