Hi On Jul 1, 8:09 am, Meikel Brandmeyer <m...@kotka.de> wrote: > That's not what I understood. I know about the trade-offs between extend and > inline methods. I blogged some time ago about it and voted for extend being > the default until speed matters. However Stuart wrote "protocols are a > low-level implementation detail".
In my understanding of the protocols, low-level is not the exact word. Protocols are designed with the implementer in mind, not the user. Sometimes user-facing API and implementer-facing API overlap but it's not a given. So, from the user point of view, protocols are an implementation detail, they are somewhat "low-level" -- lower than the user-level at least. NB: here I draw a distinction between the user which uses your API without providing his own implementation of your protocols, and the "power user"/implementer which does. Two groups with different trade- offs in API design If you have given them overlapping APIs you won't be able to change the user-facing API (eg adding fns or arities for convenience) without impacting the implementer. If you are the only implementer then your protocol is not pubic so you can get away with letting the user directly call protocol fns. > And I don't think that this is reasonable. > Take any of the collection functions: get, nth, peek, pop, seq, ... Each is > a perfect candidate for a protocol function. Why (and how) would I hide > this? I think this is a different question than using extend or inlining. conj, assoc, dissoc are counterexamples: their vararg forms can be implemented in terms of their shorter form. Let's forget that protocols fns can't be varargs. If you were specifying that conj as a protocol should accept a indefinite number of arguments, you would be putting the burden of providing this convenient signature onto the implementor, making your protocol harder to implement. That's exactly why Java frameworks are littered with abstract classes : interfaces are littered with helper methods that are tiresome to implement, so there's the abstract companion class which provide implementation of the helper methods, leaving only the core methods abstract. And as soon as you are creating a class which must implements two of such interfaces you are screwed because you won't be able to inherit implementations from two different abstract classes. Even nth and get are counterexamples too: given [coll index not-found] one can easily implement [coll index]. my 2 cents, Christophe -- 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
