It sounds like you have issue with working with something as low level as
deftype not with protocols nor how they are intended to be used. Most
people don't need to bother with equivalence or lookup - they have
defrecord.

On Monday, May 21, 2012, Mark Engelberg wrote:

> On Mon, May 21, 2012 at 4:00 PM, David Nolen 
> <dnolen.li...@gmail.com<javascript:_e({}, 'cvml', 'dnolen.li...@gmail.com');>
> > wrote:
>
>> The only two protocols that involve specifying more than 2 fns is
>> IWatchable (3) and MultiFn (5). It's not clear to me that they would
>> benefit from partial specification.
>>
>
> I don't think there's enough body of code using protocols to really know
> what is going to turn out to be the natural size for protocols but even if
> we talk about "total" reuse instead of "partial" reuse, the issue is still
> the same -- the implementation of protocols is generally locked up with no
> easy way to reuse.  If I know I want to implement ILookup the same way it
> was implemented for some other data structure, I have to be able to see
> your code, and then copy and paste it.  For some things, it is obvious how
> to reimplement, but for some it is not.
>
> When I implemented priority maps, I had a difficult time figuring out all
> the interfaces that needed to be implemented, and it was especially
> difficult to figure out the right way to implement the various notions of
> equivalence and equality.  Basically, I just wanted it to behave like the
> built-in maps.  I had to copy and paste, and shortly after I completed my
> implementation, a change was made to how these concepts were handled in the
> core.  My notion of equality became out-of-sync with that of built-in maps
> because I had no convenient way to say, "Do it the way regular maps do
> it."  I ended up having to rewrite that code.
>
> So there is a maintenance issue here too.  When Nicolas pointed out the
> many repetitions of something like the implementation of, say, ILookup,
> your response was that it would never be a big deal to just do a
> search-replace if you wanted to make a change.  But that assumes that the
> only copies occur in your own code.  When map equality changed, no one
> automatically did a search and replace in my code to make sure it would
> stay consistent.  This is why code reuse mechanisms that don't rely on
> copy/paste search/replace are valuable, especially in the core, where other
> people are trying hard to make structures that behave in a core-like way.
>
>
>  --
> 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<javascript:_e({}, 'cvml', 
> '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 <javascript:_e({}, 'cvml',
> 'clojure%2bunsubscr...@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

Reply via email to