On 7/8/12 10:58 AM, William Morgan wrote:
Excerpts from Alex Robbins's message of 2012-07-06 05:27:28 -0700:
Reading through your code, many of your functions have large cond or
condp clauses. Sometimes those can be replaced with multimethods.
Thanks, that's good to know. I think in this case the large condp
switches are part and parcel of fact that it's lexing and parsing
strings. If they get too large I may refactor into multimethods.
I was really hoping for some Clojure experts to weigh in on these
style questions below. Anyone?
(E.g. surely people don't use the repl with single-line uninformative
error messages... what am I doing wrong?)
As Ivan noted you can use (pst) to print the last stack trace. (I have
no idea why this isn't the default behavior.) The last exception is
also available in the *e variable in case you need to inspect it
(similar to Ruby's $!). As an aside, the debugging experience in emacs
is better as any error will open up a new buffer with a clickable
backtrace. I imagine some of the other editors/IDEs have similar support.
In terms of general style critique I would suggest:
* use vector literals instead of using (list ...) in your lex-item
function. [:foo] is more idiomatic than (list :foo) since the additional
syntax makes it easier to read. Of course, if a list is a better
datastructure for your needs then by all means use the list but for
small collections I don't think it really matters and so I'd prefer
vector for the reasons mentioned.
* Replace (.substring ...) with the clojure function #'subs. #'subs
is a thin wrapper for .substring.. and aside from being more clojurely
it adds type hints:
user=> (source subs)
(defn subs
"Returns the substring of s beginning at start inclusive, and ending
at end (defaults to length of string), exclusive."
{:added "1.0"
:static true}
(^String [^String s start] (. s (substring start)))
(^String [^String s start end] (. s (substring start end))))
I'll try to answer some of your other questions inline below...
- What's a good way to signal errors (e.g. parse errors)? I found the
slingshot library, which seemed to provide nice exceptions, but I'm a
little leery of pulling in a non-stdlib library just for this. Is
there a more standard way to signal exceptional circumstances?
I personally use slingshot and since it uses Clojure's new built in
custom exception I don't feel bad doing it. :) I haven't been following
this issue closely so I don't know if Clojure proper plans on adopting
more of Slingshot's functionality.
- Once a template is compiled, rather than relying on structs or hashes
to provide data, I used dynamic bindings. So you can provide a
function that fills in the data. Is this a good idea or a bad one?
(See example 1.)
About 90% of the time I have used dynamic binding I have regretted it.
You have to worry about binding conveyance (e.g. across threads-
although 1.3 fixed this) and it can allow for harder to reason about
code. As a user of your library I'd prefer a function that I could pass
the template in along with a map of variables to be subbed in. I
imagine the other clojure mustache libraries provide such an API, but
I've never used them so I can't say for sure.
- A lot of the iteration code seemed to naturally take the form:
(defn whatever [args]
(let [new-args
(some complicated stuff)]
(recur new-args)))
So all the complicated code is indented 9 spaces from the function
declaration right off the bat. Is there a better way to structure
things so that I get a little more breathing room?
I don't know if I have a good answer for this as lisp code in general
tends to be wider than other languages. It is more common in Clojure to
see private/supporting functions extracted and appear right above the
using function where in scheme you would probably see the function boxed
in within a let. For example, your #' mustache-to-string could probably
be replaced with a use of #'reduce to a private helper function.
Hope that helps,
Ben
--
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
