Armando, Thanks for the message. See below:
On Mar 7, 10:48 am, Armando Blancas <abm221...@gmail.com> wrote: > > Apparently, types/records can implement a protocol "in name only." > > That can't in name only since you obviously got an implementation, though > abstract. We agree on a couple points: -- Yes, my code did generate an implementation. Clojure will definitely consider a protocol implemented even if none of its methods are. -- Some consider this a feature: http://bit.ly/xilScm -- Abstract classes appear to be involved as an implementation detail. But I'm wondering what balance of considerations informed these semantics, since the opposite approach would seem to have advantages as well. On one hand, the current semantics have these benefits: (1) As you say, users could find it convenient to be able to implement just a few methods of a big protocol. (2) Clojure tends not to enforce limitations on access to data, so the current approach could be seen as consistent with the rest of the language. (3) The opposite approach -- requiring a type to implement all of its protocols' methods -- would make the type brittle to expansions of the protocols. (4) The current semantics do achieve high-performance polymorphic dispatch on type, which was one of the goals behind protocols. The opposite approach would be to check that a type implements all of a protocol's methods in order for it be in an extends?/satisfies? relationship with that protocol. To avoid brittleness, this check could be restricted to a subset of the protocol's methods that the protocol-designer designates :required (not sure whether this could be implemented on the JVM). The advantages I see in this approach include: (1) It's useful for protocol-writers to know that implementing types can be relied upon to respond to certain methods. This promotes reuse because code written by the protocol-writer can be confident about how to operate on data received from elsewhere whenever satisfies? returns true. This reflects the notion that a protocol is a specification. (2) Enforcing availability of a protocol's methods does not create the same rigidity problems as enforcing a concrete type system. A type can still implement multiple protocols, and anyway the type is just data and access is always available by its fields. Enforced method implementation simply provides some confidence in the protocol abstraction whenever it's claimed by the type. (3) Brittleness could be avoided by restricting the required methods to a subset that the protocol-designer labels :required. I don't know whether this could be performant on the JVM. (4) Conceptually, it just feels to me like it's part of the point of a protocol to enforce/check implementation of its methods. This is where I would most appreciate hearing alternative perspectives. Here's how I see it. Performant, type-dispatching methods could, in principle, look just like multimethods: free-standing methods that are not grouped into named protocols. Allowing methods to be grouped into named protocols therefore suggests that the point is to provide a concise way to check whether a certain collection of methods is applicable to a certain piece of data. This suggests some enforcement/checking of method implementation via something like satisfies? and extends?. I'm interested in hearing other perspectives. -- Are there important use-cases that rely on partially implemented protocols? -- Is there something about the JVM implementation that would prevent satisfies? and extends? from checking whether methods are implemented? -- Could it be that deftype/defrecord's behavior is just a bug? I notice that (doc deftype) provides, "Methods should be supplied for all methods of the desired protocol(s) and interface(s)." All the best, Garth Sheldon-Coulson P.S. I'm attracted to Tassilo's ideas about extenders. His options do match my intuitions about how this function should work if it remains available. -- 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
