2011/1/19 Ken Wesson <kwess...@gmail.com> > On Wed, Jan 19, 2011 at 8:49 AM, Laurent PETIT <laurent.pe...@gmail.com> > wrote: > > 2011/1/19 Ken Wesson <kwess...@gmail.com> > >> On Wed, Jan 19, 2011 at 4:06 AM, Laurent PETIT <laurent.pe...@gmail.com > > > >> wrote: > >> > 2011/1/18 Ken Wesson <kwess...@gmail.com> > >> >> On Tue, Jan 18, 2011 at 1:07 PM, Stuart Sierra > >> >> <the.stuart.sie...@gmail.com> wrote: > >> >> > You're not really aliasing the Vars, you're creating new Vars and > >> >> > copying > >> >> > the root values from the originals. > >> >> > This leads to subtle bugs when the original Vars are dynamically > >> >> > rebound > >> >> > or > >> >> > redefined. That's why Compojure dropped `immigrate`. > >> >> > >> >> With 1.3, one could recreate a limited 'immigrate' that only imported > >> >> the non-dynamically-bindable Vars from the target namespace. This > >> >> wouldn't cause subtle bugs, only obvious ones if a wanted Var was > >> >> dynamic and thus didn't get imported. > >> > > >> > No, because in 1.3 it will still (hopefully!) be possible to change > the > >> > root > >> > value of vars, be they dynamically rebindable or not. > >> > >> No, because alter-var-root! is an unsafe, mutating operation that > >> should not be done in production code, only at the repl during > >> testing. > > > > Where it would also be painful to have to drop/recreate namespaces using > > this export feature, every time you would alter the root value of the var > of > > an exported namespace. > > I can count on zero fingers the number of times that I, personally, > have had occasion to use alter-var-root! >
redefinition of var's root value will happen everytime you reemit defs for the same var. So unless you're using the REPL to just query the environment or start from a new REPL everytime you want to redef (eg call def again) a var, ... > > > And of course, while we agree that this should not be done in production > > code, there's by definition a difference between theory and practice, and > > "should not be done" does not equate "cannot be done", how opinionated > your > > "should" is. > > But it does mean that it's less important to avoid possibly creating > additional caveats to using something that is already best-avoided, > such as alter-var-root!. > > However, as my earlier post noted a fully general solution would be to > have a means of aliasing Vars This would certainly be a solution to the problem of the OP. -- 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