Not very clean suggestion.

Split the protocol in one protocol per function.

Instance every one on Object, with the default protocol.

Instance each specific on the function for which it has a special instance.

On Fri, Jul 16, 2010 at 7:45 PM, tbatchelli <tbatche...@gmail.com> wrote:

> Hi all,
>
> I am writing a network protocol handler based on events (to wrap
> netty, if you're curious). I created a protocol that defines the
> functions needed to handle every possible (channel) event:
>
> (defprotocol channel-handler-strategy
>  (message-received [this ctx evt])
>  (exception-caught [this ctx evt])
>  ...
>  )
>
> And I also provide a default event handler that will call the
> appropriate handler function of the channel-handler-strategy protocol
> depending on the type of event and some other data, for example:
>
> (defrecord simple-channel-handler [strategy]
>  channel-handler
>  (handle-upstream [this ctx evt]
>                   (if (= ctx "hello")
>                     (message-received strategy ctx evt)
>                     (exception-caught strategy ctx evt))))
>
>  Note: this is toy code, the real code hasn't been written yet ;)
>
> Here is the problem I am trying to solve: the list of handler
> functions that the protocol will define is loooong, and for most of
> the cases, the developer will only want to perform some custom logic
> in one or two of the handler functions, expecting that the rest of the
> handler functions will perform some sort of default action (forward
> the event in this case). If my understanding of the new type system in
> 1.2 is correct, there is no way create a record by extending another
> record, nor a way to override functions of a record. Thus, with the
> current tools, every channel-handler-strategy implementor would have
> to provide a definition for *all* the functions defined in the
> protocol.
>
> I thought of some solutions, but I get the feeling I might just be
> approaching the problem from the wrong angle.
>
> 1) The channel-handler-stategy implementor only implements the handler
> functions he/she cares about, leaving the rest unimplemented. When the
> event handler calls one of the unimplemented handler functions and
> exception will be thrown,  and so the event handler can catch them and
> execute the default behavior.
>
> 2) If there was a way to build a record from a map e.g: {fn-name fn-
> definition}, then I'd be able to create a default handler function map
> which the channel-handler-strategy implementors would merge with their
> own custom maps that contained only the redefined handler functions,
> and then use this merged map to create the record. I could not find
> any existing way to do this but I believe it should be possible to
> write a macro to do create a record from such map.
>
> 3) Use structs, but that would be too slow for my use case.
>
> So here is the question: Am I approaching this problem the wrong way?
> Or this use case for types is an only edge case and I should go ahead
> and build a custom solution based on any of the above proposed
> solutions?
>
> Thanks in advance for your thoughts,
>
> Toni.
>
>
>
>
>
> --
> 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<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