Note that there are some explanatory texts on larger screens.

plurals
  1. POHow do I properly structure a package with sub packages in Go where a single type will be the receiver on most of the methods?
    primarykey
    data
    text
    <p>I am just starting to pick up Go, so if I've missed something obvious, Go easy :-)</p> <p>Anyway, I'm currently in the design stage of writing a utility library that will make interaction with the <a href="http://code.google.com/p/x-go-binding/" rel="nofollow">x-go-binding</a> a bit easier. (I've done this before with Python and xpyb.) For example, it will help with querying information defined in the <a href="http://standards.freedesktop.org/wm-spec/wm-spec-latest.html" rel="nofollow">EWMH spec</a> and binding keys to callback functions. (And much more.) So as my initial idea for a package layout, consider:</p> <ul> <li>xutil <ul> <li>ewmh</li> <li>keybind</li> </ul></li> </ul> <p>Where each is its own package. (Similar to how the standard library's image package is setup.)</p> <p>What's unique about my situation is that almost every x-go-binding call requires some combination of an xgb connection object or a root window identifier. Therefore, it makes sense to me to store this information in a struct like so:</p> <pre><code>type XUtilConnection struct { conn xgb.Conn root xgb.Id // a few other things, like a mapping of events to callbacks } </code></pre> <p>So that I'd have a factory that could be used like so:</p> <pre><code>xconn = xutil.NewXUtilConnection(blah blah) </code></pre> <p>And it could be used like:</p> <pre><code>xconn.get_active_window() xconn.bind_key("Shift-a", my_callback_fun) </code></pre> <p>There may also be functions like:</p> <pre><code>keybind.get_keycode("a") ewmh.get_atom("_NET_ACTIVE_WINDOW") </code></pre> <p>My problem of course is that receivers, to my knowledge, can only be of types that have been declared in the same package. If I separate my packages, I cannot use my XUtilConnection type as a receiver in any of my sub-packages.</p> <p>I suspect that my answer is going to be making this one big package separated into different logical files, but I fear that this might lead to namespace clutter. (For example, implementing the EWMH spec is probably on the order of 100+ functions.)</p> <p>I am also aware that I could define a new container type in each sub-package for my XUtilConnection object. (I've heard that this should be a struct containing a single member XUtilConnection to avoid casting.) But this seems like a really messy situation to me, and would prevent the kind of semantics I'd like. (i.e., using an XUtilConnection struct to call methods in several different modules.)</p> <p>Any advice at any place in my design process would be greatly appreciated. Thanks!</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload