FAQ
Hi all,

   I've got another debatable design question :)

   I'm trying to put together a nice API, and one issue I'm struggling with
is the concept of an event handler with a single method. The interesting
issue is the choice and rationale behind one-method-interface vs. method
alias.

Example:

type Handler interface {
   HandleEvent(event) error
}

vs.

type Handler func(event) error

If I expect more methods to be added later, then the first choice is the
obvious one. But if I'm (pretty) sure it will remain like this "forever",
then in the case of simpler handlers, the first one requires extra
boilerplate of defining a handler struct, whilst a simple method pass would
have done it. On the other hand if I choose the second, I can still simply
use somestruct.HandleEvent as the handler if it requires a more complex
handler.

My dilemma is pretty much present in the Go http package:
http://golang.org/pkg/net/http/#Handler vs.
http://golang.org/pkg/net/http/#HandlerFunc.

So what are your 2 cents? :)

Cheers,
   Peter

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Kevin Malachowski at May 16, 2013 at 9:39 pm
    For me, if you know the method will never need to keep state then you might as well use the typedef to func to keep it simple. If you need to keep state an interface seems more appropriate for the obvious reason of it being easier for a struct to keep the state than package-level variables.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Christoph Hack at May 16, 2013 at 10:02 pm

    Am Donnerstag, 16. Mai 2013 22:21:04 UTC+2 schrieb Péter Szilágyi:

    My dilemma is pretty much present in the Go http package:
    http://golang.org/pkg/net/http/#Handler vs.
    http://golang.org/pkg/net/http/#HandlerFunc.
    I think the dilemma is elegantly solved in the http package by adding a
    ServeHTTP method to the HandlerFunc type, so that it implements the Handler
    interface as well. Have you looked at the sources too?

    http://golang.org/src/pkg/net/http/server.go?s=33108:33155#L1135

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Péter Szilágyi at May 16, 2013 at 10:48 pm
    Hi,

    Kevin, I agree with the logic, but since I can pass in a struct's member
    function as an aliased handler (see http://play.golang.org/p/UOyVYlSBGN), I
    can have state too if needed, and quite simply too.

    Christoph, I saw the solution (hence why I linked it in :P), but I think
    it's an ugly hack :D In my opinion the interface was born first, and then
    by popular demand they hacked in a way to specify simple functions too as
    handlers. Nonetheless it did occur to me to use that solution, but decided
    that - for the current purposes - I'd like an API as simple as possible,
    thus I'd like to offer only one "official" way of doing things.

    I'm a bit inclined towards the function aliasing solution, but I was
    wondering whether there are any non obvious drawbacks that I'm not seeing.

    Cheers,
       Peter

    On Fri, May 17, 2013 at 12:01 AM, Christoph Hack wrote:

    Am Donnerstag, 16. Mai 2013 22:21:04 UTC+2 schrieb Péter Szilágyi:

    My dilemma is pretty much present in the Go http package:
    I think the dilemma is elegantly solved in the http package by adding a
    ServeHTTP method to the HandlerFunc type, so that it implements the Handler
    interface as well. Have you looked at the sources too?

    http://golang.org/src/pkg/net/http/server.go?s=33108:33155#L1135

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMay 16, '13 at 8:21p
activeMay 16, '13 at 10:48p
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2023 Grokbase