On Dec 2, 12:29 am, Krukow <karl.kru...@gmail.com> wrote:
> On Dec 1, 10:56 pm, Rich Hickey <richhic...@gmail.com> wrote:
> [snip]
>
> > There are 2 ways to make a deftype reach a protocol. First, you can
> > implement the protocol directly in the deftype/reify, supplying the
> > protocol where you do interfaces, and the methods of the protocol as
> > methods of the type. The type will be made to implement the protocol's
> > interface.
>
> OK. With extend you can use maps and merge to share implementations.
> Does directly implementing the protocol in deftype allow also for
> "abstract super-classes", i.e., sharing protocol-function
> implementations across types?
>
Right now you would just call an implementation helper inside your
method. I'm still considering if more support is needed, and what form
it might take.
> > Different methods of implementing the protocol have different
> > performance. Implementing directly in deftype or reify is as fast as a
> > direct interface call. Using extend-* is not quite as fast, but still
> > fast. Both methods have direct support in callsites, so a call to a
> > protocol fn has support both for using the interface and caching
> > lookup results.
>
> Great. So the preferred way for data-types in my program is to
> implement the protocol directly, whereas for other types I can still
> use my protocol with extend.
>
> Just to confirm my understanding: Is it correct to say, for example,
> that clojure.lang.Seqable will be a protocol implemented directly in
> the Clojure data types, whereas it would reach the Java lang types
> using extend?
>
Yes. extend is the key to removing the current (closed) multiway
conditionals in, e.g., RT.seq/seqFrom, and is much faster as well.
> In Clojure-in-Java interfaces like IPersistentCollection extend
> Seqable: would these be unrelated type-wise as protocols?
>
Yes. One of the reasons we use interface inheritance in a language
like Java is that, short of generifying everything, we have no way to
say:
foo(Counted+Sorted+Seqable+Collection coll){...}
We only get to specify one type, and any other interfaces it doesn't
imply require casts. So we use hierarchy to reduce the required
casting, but it has a cost in flexibility - i.e. you can't make a non-
Seqable collection, if that made sense.
In a dynamic language with protocols there is no reason to do it this
way. You don't need to have a single type imply multiple types via
hierarchy, and you don't need to declare anything. So each protocol is
a la carte, and a piece of code that requires the collection support
Counted, Sorted, Seqable and Collection protocols will simply use
those protocols, and work with anything that supports them. A type can
support any and just the protocols that make sense for it, without
bringing in others as a side effect of hierarchy.
Protocols are very much about polymorphism without hierarchy.
Rich
--
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
