On Tue, Apr 30, 2013 at 10:51 AM, Tassilo Horn <t...@gnu.org> wrote:
> "Jim - FooBar();" <jimpil1...@gmail.com> writes:
>
> > funny you should mention that!!! that is exactly what I meant by 'my
> > fault'...I've come to realise that dynamic scope is almost evil, thus
> > I go to great lengths to avoid it completely...in the rare cases where
> > I do use it I always make sure it is bound to a init/default value :)
>
> I do exactly the opposite when I use dynamic vars, that is, I define no
> default value. For example, there's a function foo that uses a dynamic
> var, and that must be bound and well-defined. Therefore, I provide a
> macro to initially set it up, so that you write
>
> (with-bar (foo bla))
>
> and with-bar takes care of the proper initialization of that dynamic var
> (which is not even visible to the user). When foo explodes because of
> the var being Unbound, then it's obvious that the function was called
> outside a with-bar macro and thus is a user error. A default value
>
the thing is, that it may not always explode if not used with with-bar,
depending on the implementation of the function, as if when used in an
(cond (nil? thevar) ... ) or (str thevar)
If you ask me, I'd allow the var to be unbound and code everywhere for
cases where the var could be unbound - which there should be many ie. any
function; so I can understand why people would want to take the
easy/workaround way and set a default value instead.
=> (defn decorate [input]
(str "prefix:" input ":suffix")
)
#'jme3test1.x1/decorate
=> (def ^:dynamic *y*)
#'jme3test1.x1/*y*
assume I forget to use with-bar here:
=> (decorate *y*)
"prefix:Unbound: #'jme3test1.x1/*y*:suffix"
didn't explode
or here:
=> (defn do-smth-with [input]
(when (not (nil? input))
(str "doing something with " input))
)
#'jme3test1.x1/do-smth-with
=> (do-smth-with *y*)
"doing something with Unbound: #'jme3test1.x1/*y*"
=> (do-smth-with *x*)
"doing something with 2"
=> (decorate *x*)
"prefix:2:suffix"
=> (do-smth-with nil)
nil
I guess what I was trying to say all along is that it's too easy to fall
into this by mistake because maybe most don't check for unbound and it may
not explode
would shadow such an error.
>
> A real-world example of this design are many database query libs, where
> you frequently have code like
>
> (with-db-connection (make-me-a-db-connection url)
> (select :from "foo" :where ...))
>
> Bye,
> Tassilo
>
> --
> --
> 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/groups/opt_out.
>
>
>
--
--
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/groups/opt_out.
