It seems to me that defmulti should create a new instance of MultiFn,
initialized with the method tables from the existing MultiFn, if any.
Then alter-var-root to update the Var holding the MultiFn.
A possible problem is that a new dispatch function might be inconsistent
with the existing keys a
After moving a clj file and updating its ns declaration, subsequently
updating a ns form that :require's it causes the REPL to bark. Restarting
the REPL recovers from it.
Here is a self-contained demo. Instead of making a ns to move, and moving
it, I illustrate by recycling the same ns requ
I was bitten by this multi-method problem this week and so, coincidentally
was a newbie friend of mine.
This trick works perfectly and got me (us) out of the hole.
Given the recent (very worthy IMHO) marketing efforts for the REPL can we
have an update on what mitigations are in place for this
On Wed, Sep 5, 2012 at 12:31 AM, Brian Marick wrote:
> I'm trying to write exercises for multimethods. Book readers will be
> working at the repl. Multimethods are stateful in a bad way, as shown
> below. Is there some sort of trick to using multimethods at the repl, or
> should I just give up on
Stuart Halloway writes:
> I started a wiki page for this:
>
> http://dev.clojure.org/display/design/Never+Close+a+REPL
>
> I believe these problems could be entirely solved in a contrib library
> of helper functions for REPL development. This a significantly better
> than making changes to Cloju
On Fri, Sep 7, 2012 at 9:56 AM, Laurent PETIT wrote:
> 2012/9/5 Stuart Halloway :
>> I started a wiki page for this:
>>
>> http://dev.clojure.org/display/design/Never+Close+a+REPL
>>
>> If you have other REPL-reloading annoyances please add them there.
>
> Adding new dependencies to my Leiningen p
2012/9/5 Stuart Halloway :
> I started a wiki page for this:
>
> http://dev.clojure.org/display/design/Never+Close+a+REPL
>
> If you have other REPL-reloading annoyances please add them there.
Adding new dependencies to my Leiningen project.
Solved by pomegranate ?
I think I could add an experim
On Sep 5, 2012, at 11:58 AM, Stuart Halloway wrote:
> I share your pain. A standardized contrib solution for this would be
> welcomed.
>
What I'm doing will be somewhat specific to the chapter in the book. But if it
matters, it will be here:
https://github.com/marick/fp-oo/blob/master/sourc
This is what I started working on tools.namespace to solve.
I came to the conclusion that it's impossible to make something that works
in 100% of all cases, but I'm hoping to get to 90%.
I added some notes to the wiki page too.
-S
--
You received this message because you are subscribed to the
I started a wiki page for this:
http://dev.clojure.org/display/design/Never+Close+a+REPL
If you have other REPL-reloading annoyances please add them there.
Stuart Halloway
Clojure/core
http://clojure.com
> Kevin Downey writes:
>
>> if I recall, the current defonce like behavior of multimethod
Kevin Downey writes:
> if I recall, the current defonce like behavior of multimethods was a
> response to the situation where if you have your multimethods split
> across multiple files reloading the file with the defmulti in it would
> re-def the multimethod with the new dispatch, but it would n
if I recall, the current defonce like behavior of multimethods was a
response to the situation where if you have your multimethods split
across multiple files reloading the file with the defmulti in it would
re-def the multimethod with the new dispatch, but it would not have
any of the methods load
Stuart Halloway writes:
> Are there other things like this that cause people to "restart REPL"
> unnecessarily? I would like to identify the whole list of such things and
> kill them.
Maybe related. Ritz has slime-load-file hooked up to code that tries to
remove dead vars from a namespace. i.e
Brian,
I share your pain. A standardized contrib solution for this would be welcomed.
Are there other things like this that cause people to "restart REPL"
unnecessarily? I would like to identify the whole list of such things and kill
them.
Stu
> Thanks. I think I'll write my own `defgeneric`
Thanks. I think I'll write my own `defgeneric` to hide an `ns-unmap` from the
reader. (I like the terminology of "generic function" better than multimethod
anyway, as an introduction to the idea.)
On Sep 4, 2012, at 5:41 PM, Ulises wrote:
>> Binding to the var instead of the value will allow i
> Binding to the var instead of the value will allow it to be udpated.
Alternatively you could ns-unmap the multimethod before redefining it.
U
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups
> user=> (defmulti collide classify-colliding-things)
You want (defmulti collide #'classify-colliding-things)
Binding to the var instead of the value will allow it to be udpated.
jack.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
On Tue, 2012-09-04 at 17:31 -0500, Brian Marick wrote:
> user=> (defmulti collide classify-colliding-things)
If you're okay with a little handwaving, how about
(defmulti collide #'classify-colliding-things)
Now there is no need to rerun defmulti.
--
Stephen Compall
"^aCollection allSatisfy: [:
I'm trying to write exercises for multimethods. Book readers will be working at
the repl. Multimethods are stateful in a bad way, as shown below. Is there some
sort of trick to using multimethods at the repl, or should I just give up on
exercises using them?
;; Two types:
user=> (defn ship [na
19 matches
Mail list logo
