Well, I'm not totally sure about what I'll write below, but I'll still try to make a decent job of sharing my current thoughts:
* first, when I see calls to (instance?) (satisifies?), it rings a bell in my head. "design problem". * second, it seems like you're trying to "fix in the concrete" something which may not have to. Having "coolness" be a static property of implementing this and that protocol seems very "fixed". Beware the fixed hierarchies in java when you then have hard times getting orthogonal code (given that java has no implementation multiple inheritence, for example). But maybe it's just the example (or even me not totally understanding the example). * third: looks like a protocol abuse. I have the impression that the current "trend" is to see protocols as fine-grained "extension points" of generic algorithms. Which implies that the public API is not protocol functions, but those "regular functions" to which you pass objects which happen to be extended to some protocols (with you the consumer being aware of it or not). So a library implementer has designed some interesting generic functions. He organizes the way these generic functions deal with different types of input by creating protocols and calling protocol functions on the inputs, and extends those protocols to the most relevant kinds of input types (for him). He then decides to make the protocols part of his public API to let you, the user, have the ability to benefit from the generic functions for your own specific kinds of types. In this scheme, the goal is less "extending the protocol for the sake of it" than "extending the protocol to be able to leverage existing functions *using* the protocols to one's particular kind of types/records". If the design of your application requires the use of protocols at all, which should generally not be an implicit assumption, IMHO. 2010/11/4 ka <sancha...@gmail.com>: >> AFAIK, it is not possible. You must implement all the different protocols. >> It might look desapointing, but on the other hand it is not necessary. >> (As there is no static typing in Clojure) >> What is your use-case? > > Current use case is that I want an abstraction which comprises of a > set of operations I want + Comparable + Serializable > >> Just define types that extend all the protocols. >> You can't. But you can define a type that extends both P and Comparable. > > Currently I'm struggling with the following problem - Suppose I > consider something satisfying 'Coolness' property if it does x, y, z + > is comparable + serializes. > > To do this I create a protocol 'OnlyHalfCoolness': > (defprotocol OnlyHalfCooless x y z) > > and two deftypes Cool1, Cool2: > (deftype Cool1 ... OnlyHalfCoolness .. Comparable .. Serializable) > (deftype Cool2 ... OnlyHalfCoolness .. Comparable .. Serializable) > > Now I need to write a function: is-this-cool? > > Instead of > (defn is-this-cool? [o] (satisfies? Coolness o)) > > I need to now write: > (defn is-this-cool? [o] (or (instance? Cool1 o) (instance? Cool2 o)) > or, (even worse) > (defn is-this-cool? [o] (and (satisfies? OnlyHalfCoolness o) > (instance? Comparable o) (instance? Serializable o)) > > A type hierarchy is not required - but I think a way to compose > (atleast union) abstractions would be nice. > > Are there some fundamental problems with - (defprotocol Coolness .. > Comparable .. Serializable .. x y z) ? > >> What do you mean by "static" functions? > > Normal functions which do not dispatch based on the type of their > first argument. Forget about this - thinking more about it - they > don't really make too much sense in protocols. > > > -- > 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
