Michal: Thanks a lot. This is very helpful. I have not given much thought yet on the implementation, but there seems to be obstacles:
1. get the protocol method implementation dynamically (your suggestion solved part of it) 2. metadata can only be attached to symbols, not the types themselves. But I might be able to work around it with closures. I am trying to avoid using multimethods as I hope I can just add a very thin layer on top of protocols so after the changes protocols are still protocols and have minimum impact on the current system. If this works, I hope it will satisfy 99% of my needs and I will leave multimethod to the remaining 1%. But again, it may not work as I have not really thought through it. On Tuesday, July 3, 2012 4:13:20 PM UTC-4, Michał Marczyk wrote: > > On 3 July 2012 18:40, Vinzent <ru.vinz...@gmail.com> wrote: > > Well, as far as I understand, protocols was made as they were on > purpose, so > > inability to create hierarchies is a "feature" (like it or not), while > the > > lack of `get-method`-like thing is clearly a defect (in my mind). > > You can get hold of a protocol's implementation for a particular type > if it was attached to a type with extend / extend-type / > extend-protocol: > > (defprotocol IFoo (foo [x])) > (deftype Foo [x] IFoo (foo [_] x)) > (deftype Bar [x]) > (extend-protocol IFoo Bar (foo [x] (.-x ^Bar x))) > > user=> (get-in IFoo [:impls user.Foo :foo]) > nil > user=> (get-in IFoo [:impls user.Bar :foo]) > #<user$eval39$fn__40 user$eval39$fn__40@30c06258> > > :foo here is the keywordized method name. > > Implementations specified inline in a deftype/defrecord form cannot be > so obtained, because they only exist as JVM methods. Basically by > inlining an implementation you gain speed at the cost of some dynamic > / reflective capabilities. > > You can also build implementation maps in a dynamic fashion when using > extend (a regular function, unlike extend-protocol and extend-type > which are macros); I believe there are some examples floating around > in the group archives. Inlined implementation sharing requires some > macrology, see for example the implementation of records. > > Cheers, > Michał > > > > > > Anyway, you have multimethods which can do almost anything, so I think > it'd > > be a good idea to implement proof-of-concept of what you have in mind > and > > publish it on Github, so people could try it and compare to what they > > already have. > > > > вторник, 3 июля 2012 г., 21:13:27 UTC+6 пользователь Warren Lynn > написал: > >> > >> > >> > >> On Tuesday, July 3, 2012 4:18:44 AM UTC-4, Vinzent wrote: > >>> > >>> I believe the protocol's analogue for get-method would be enough. > >>> > >>> > >> > >> If here you mean we just need to use get-method to directly reuse a > >> protocol method anywhere, I think that is not adequate. We need to > maintain > >> the hierarchy structure so even at run time we can re-define parent > protocol > >> methods and things will still work as expected for the derived type. > >> Although, I also feel the free-style re-use of any method from anywhere > >> (instead of always bundle all methods in one protocol together and > following > >> a hierarchy) may create some chaotic code structure that is difficult > to > >> understand, maintain and communicate with other developers. > >> > >> But get-method can be a building block here of course, and may be handy > >> for those cases you do need ad-hoc re-use of some code. > > > > -- > > 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
