Chas,
thank you for the explanation, it confirmed my vague thoughts I had after
quick review of Clojure source code and inspection of values in prototype
maps before and after the change.
I understand the difference, however I think there are three points to
consider from Clojure design point of view.
1) If you target both Clojure and ClojureScipt, you cannot write #'foo,
because variables are not first class citizens in CLJS (yet).
2) Functional code is a lot about passing functions to functions making
functions (for example wonderful reducers library). Does it mean we should
always pass around variable instead of methods (because we cannot foresee
if a programmer extending our code will use defrecord or extend)?
3) The point is the inconsistency in `defrecord` and `extend`
implementation. I always thought about defrecord and extend as a "syntactic
sugar" to achieve same goal. If there are two ways how to implement a
protocol, they should lead to same results and side effects otherwise it
could backfire on us and result in hard to discover bugs.
For example, if defprotocol is implemented in namespace A, transmogrify and
foo* in namespace B and FooRec and BarRec were implemented in namespace C,
I get different results if I load namespaces in sequence A-B-C and A-C-B.
This is very dangerous indeed.
For me the real issue is point 3) as it crosses the boundary of principle
of least surprise. There are two ways how to implement a protocol in a
record and your code may or may not throw an exception under different
conditions.
So my recommendation would be to unify defrecord and extend implementation.
Dan
On Sunday, June 24, 2012 4:35:10 AM UTC+2, Chas Emerick wrote:
>
> Dan,
>
> This difference is due to the subtleties around how protocols are
> implemented, and between passing a var vs. capturing a var's state at a
> particular time.
>
> If you change `transmogrify` to this (note the #'), the `(foo* (BarRec.))`
> succeeds:
>
> (*def* foo* (transmogrify #'foo "Bar"))
>
> Protocol implementations are largely tracked by a map held in a var
> corresponding to the protocol's name (in this case, FooProto). Prior to
> using `extend`, the #'FooProto var contains this map:
>
> {:on-interface user.FooProto, :on user.FooProto, :sigs {:foo {:doc "Make a
> foo", :arglists ([X Y]), :name foo}}, :var #'user/FooProto, :method-map
> {:foo :foo}, :method-builders {#'user/foo #<user$eval1287$fn__1288
> user$eval1287$fn__1288@610f7612>}}
>
> After using `extend`, it contains this map (note the `:impls` slot):
>
> {:impls {user.BarRec {:foo #<user$eval1321$fn__1322
> user$eval1321$fn__1322@1e384de>}}, :on-interface user.FooProto, :on
> user.FooProto, :sigs {:foo {:doc "Make a foo", :arglists ([X Y]), :name
> foo}}, :var #'user/FooProto, :method-map {:foo :foo}, :method-builders
> {#'user/foo #<user$eval1287$fn__1288 user$eval1287$fn__1288@610f7612>}}
>
> The implementation of protocol functions is such that they retain
> optimized (fixed) call paths for each type extended to their protocol.
> Thus, when you pass the value of `foo` to `transmogrify`, the un-extended
> protocol's "configuration" goes with it. However, if you pass the var
> #'foo instead, all calls through #'foo are guaranteed to utilize the most
> up-to-date protocol function, and therefore the most up-to-date protocol
> type extensions. In any case, calling `(foo …)` always works, because that
> call implicitly goes through #'foo anyway.
>
> The fine difference between capturing a var's value vs. passing or calling
> through the var itself is a frequent tripping hazard, but understanding it
> is especially important in ensuring maximum productivity and enjoyment in
> the REPL (as you've found out). FWIW, we talk about this issue with some
> simpler examples illustrating the subtleties in chapter 10 of the book (in
> a subsection of REPL-Oriented Programming, ~page 416, 'Understand when
> you’re capturing a value instead of dereferencing a var').
>
> Hope this helps,
>
> - Chas
>
> --
> http://cemerick.com
> [Clojure Programming from O'Reilly](http://www.clojurebook.com)
>
> On Jun 23, 2012, at 7:45 PM, Daniel Skarda wrote:
>
> Hi,
>
> I have discovered strange difference between methods implemented directly
> in defrecord and methods added later using extend (extend-type).
>
> I simplified the issue to code example listed bellow. Both records FooRec
> and BarRec implement simple protocol FooProto with method foo. There is
> also evil function transmogrify, which takes a function F and returns new
> function which calls F. I use transmogrify to produce function foo*
>
> If you call foo method directly, everything works as expected. When you
> call foo*, FooRec method is OK, but BarRec fails with following exception
>
> No implementation of method: :foo of protocol: #'user/FooProto found for
> class: user.BarRec
>
>
> Which looks weird because you can call foo directly...
>
> I expect that defrecord and extend use different approach to extending the
> type and foo* ends up with a reference to old version of protocol.
> `defrecord` somehow manages to modify directly the protocol definition
> referenced by foo*, while `extend` takes more immutable approach and
> replaces old protocol definition (which foo* cannot see). I briefly dived
> into Clojure sources and found that indeed `extend` ends with some sort of
> alter-root-var, while `defrecord` traces ends deep in java sources
> (deftype*).
>
> It would be good idea to unify defrecord and extend so they have same
> behaviour.
>
> Dan
>
> (defprotocol FooProto
> (foo [X Y] "Make a foo"))
>
> (defn transmogrify [F Y]
> (fn [A] (F A Y)))
>
> (def foo* (transmogrify foo "Bar"))
>
> (defrecord FooRec []
> FooProto
> (foo [X Y] (println "Hello," Y)))
>
> (foo (FooRec.) "World")
> ; -> Hello, World
>
> (foo* (FooRec.))
> ; -> Hello, Bar
>
> (defrecord BarRec [])
>
> (extend-type BarRec
> FooProto
> (foo [X Y] (println "Bar" Y)))
>
> (foo (BarRec.) "Bar")
> ; -> Bar Bar
>
> (foo* (BarRec.))
> ; bang!
>
> ; No implementation of method: :foo of protocol: #'user/FooProto found for
> class: user.BarRec
>
>
>
> --
> 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 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
