OK, I get it now. Protocols are attached to very specific capabilities.
With this structure, it is easy to: Write a function that operates on an input that fulfills a specific protocol. Write a function that operates on an input that fulfills (all of) multiple protocols. Write a function that operates on a closed (non-extensible by outsiders) union of abstract data types (i.e., it satisfies *either* this protocol or that protocol). Write a function that has a default case, and can be extended by other concrete data types. Write a function that supports a closed union of abstract data types, but can still be extended by other concrete types. Pretty much the only thing you can't do with protocols is: Write a function that supports an open union of abstract data types, for example: "I want this function to be able to work with objects that support nth, or objects that support the protocol for queues, and I want to leave it open to other kinds of abstract protocols I might not be able to think of right now." It's a limitation for sure. It is easy to think of scenarios like last where you want to offer one implementation for the abstract concept of sequential types, one for the abstract concept of reversible types, one for the abstract concept of random access types, and possibly leave it open for extension. But I can see why this kind of need for abstract extensibility might be rare, given the many other combinations that are well-supported by protocols. Regarding the specific use-case of last, in theory, I think it could be done in almost exactly the same way that nth is implemented. last would dispatch to a protocol containing -last to provide an extension point for concrete data types, and in a cond could test to see if various abstract protocols were satisfied, and if so use the corresponding last implementation. There's no point of extension for other abstract protocols, but that's not a huge deal (and certainly no worse than the current implementation which only supports one abstract protocol!) I don't feel strongly about last specifically, but if people wanted it to behave polymorphically, I'd be happy to volunteer to write the code. In any case, I feel like I understand better how you've structured things in ClojureScript and what can and can't be done easily with protocols. Thanks! -- 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
