On Wed, Dec 22, 2010 at 1:29 PM, Nicolas Buduroi wrote:
> On Dec 22, 1:03 pm, David Nolen wrote:
> > (Foo.) is a Java method call determined at compile-time. If you change
> the
> > definition of the Foo type/record, create-foo will be out of date.
> Default
> > constructor fns could alleviate t
On Dec 22, 1:03 pm, David Nolen wrote:
> (Foo.) is a Java method call determined at compile-time. If you change the
> definition of the Foo type/record, create-foo will be out of date. Default
> constructor fns could alleviate this but I think some design/modularity
> issues need to be hashed out.
> of method" exceptions and I really don't understand why
Working with protocols/deftype/defrecprd generally requires that you
recompile the whole file when you make a modification. If you stick to that
you'll avoid a lot of confusing REPL states.
Consider:
(defn create-foo []
(
launched from Leiningen. I'm using the REPL to test my code
and after I've changed a file I use slime-eval-buffer. I wonder if
there's some general issues with this setup or advices on working with
protocols that can help me?
Thanks
--
You received this message because you
