FAQ
I am building some functionality that seems to fit best in the existing Go
packages. For a very simple example related to a previous thread I started,
where I need to sleep till pretty close to the boundary of the next N
seconds into the future,

func DurationTillBoundary(interval int64) time.Duration {
now := time.Now()
// This many ns till the next second boundary
ns := time.Second.Nanoseconds() - int64(now.Nanosecond())
// This many sec till the next desired seconds
sec := interval - (now.Unix() % interval) - 1
return time.Duration(sec * time.Second.Nanoseconds() + ns)*
time.Nanosecond
}

That's what I wrote in my little throwaway script, but what I should have
written, I believe, is

func (t *time.Time) DurationTillBoundary(....

This feels like it belongs in the time package in my own package hierarchy.
Should I do that? That would effectively add onto the existing time
package. Or maybe I should add a new time/timeutil package instead? Or
should I root my package hierarchy like in Java, where I would do
org.MyCompany.time instead? What are your experiences and what practices do
you suggest? I expect that I will eventually have a very large codebase
with probably hundreds of packages, so now is the best time for me to
figure out how to do this.

I have several other examples, such as container/fifo and some things that
ought to go into math or mathutil.

Thanks
Boris

--

Search Discussions

  • Stevewang at Nov 15, 2012 at 6:48 pm
    Is this what you want?


    1. package main
    2. import "fmt"
    3. import "time"
    4. type MyTime struct {
    5. time.Time
    6. }
    7. func (p *MyTime) DurationTillBoundary(interval int64) time.Duration {
    8. now := time.Now()
    9. // This many ns till the next second boundary
    10. ns := time.Second.Nanoseconds() - int64(now.Nanosecond())
    11. // This many sec till the next desired seconds
    12. sec := interval - (now.Unix() % interval) - 1
    13. return time.Duration(sec * time.Second.Nanoseconds() + ns)* time.Nanosecond
    14. }
    15. func main(){
    16. t := &MyTime{time.Now()}
    17. fmt.Println(t.Day()) // use it as time.Time
    18. fmt.Println(t.DurationTillBoundary(100))
    19. }

    On Friday, November 16, 2012 2:28:38 AM UTC+8, Boris wrote:

    I am building some functionality that seems to fit best in the existing Go
    packages. For a very simple example related to a previous thread I started,
    where I need to sleep till pretty close to the boundary of the next N
    seconds into the future,

    func DurationTillBoundary(interval int64) time.Duration {
    now := time.Now()
    // This many ns till the next second boundary
    ns := time.Second.Nanoseconds() - int64(now.Nanosecond())
    // This many sec till the next desired seconds
    sec := interval - (now.Unix() % interval) - 1
    return time.Duration(sec * time.Second.Nanoseconds() + ns)*
    time.Nanosecond
    }

    That's what I wrote in my little throwaway script, but what I should have
    written, I believe, is

    func (t *time.Time) DurationTillBoundary(....

    This feels like it belongs in the time package in my own package
    hierarchy. Should I do that? That would effectively add onto the existing
    time package. Or maybe I should add a new time/timeutil package instead? Or
    should I root my package hierarchy like in Java, where I would do
    org.MyCompany.time instead? What are your experiences and what practices do
    you suggest? I expect that I will eventually have a very large codebase
    with probably hundreds of packages, so now is the best time for me to
    figure out how to do this.

    I have several other examples, such as container/fifo and some things that
    ought to go into math or mathutil.

    Thanks
    Boris
    --
  • Boris at Nov 15, 2012 at 7:12 pm
    My question is more about what's the best way to arrange package and type
    hierarchies with respect to Go's provided packages. Is there a Go-ism for
    the right way to do this already? Or is it something that hasn't become a
    convention yet? I don't need a MyTime, I could just use time.Time builtin,
    but if that is not seen as best practice it is something I want to learn.
    On Thursday, November 15, 2012 1:48:29 PM UTC-5, stevewang wrote:

    Is this what you want?


    1. package main
    2. import "fmt"
    3. import "time"
    4. type MyTime struct {
    5. time.Time
    6. }
    7. func (p *MyTime) DurationTillBoundary(
    --
  • Stevewang at Nov 15, 2012 at 7:16 pm
    Well, should I view your question as "how to organize my go code"?
    If so, there already is an official article about it:
    http://blog.golang.org/2012/08/organizing-go-code.html
    On Friday, November 16, 2012 3:05:35 AM UTC+8, Boris wrote:

    My question is more about what's the best way to arrange package and type
    hierarchies with respect to Go's provided packages. Is there a Go-ism for
    the right way to do this already? Or is it something that hasn't become a
    convention yet? I don't need a MyTime, I could just use time.Time builtin,
    but if that is not seen as best practice it is something I want to learn.
    On Thursday, November 15, 2012 1:48:29 PM UTC-5, stevewang wrote:

    Is this what you want?


    1. package main
    2. import "fmt"
    3. import "time"
    4. type MyTime struct {
    5. time.Time
    6. }
    7. func (p *MyTime) DurationTillBoundary(
    --
  • Boris at Nov 15, 2012 at 7:33 pm
    I think that article has what I am looking for:

    If you don't use a hosted source repository, choose some unique prefix such
    as a domain, company, or project name. As an example, the import path of
    all Google's internal Go code starts with the string "google".

    On Thursday, November 15, 2012 2:16:39 PM UTC-5, stevewang wrote:

    Well, should I view your question as "how to organize my go code"?
    If so, there already is an official article about it:
    http://blog.golang.org/2012/08/organizing-go-code.html
    On Friday, November 16, 2012 3:05:35 AM UTC+8, Boris wrote:

    My question is more about what's the best way to arrange package and type
    hierarchies with respect to Go's provided packages. Is there a Go-ism for
    the right way to do this already?
    --
  • Bryanturley at Nov 15, 2012 at 7:29 pm

    On Thursday, November 15, 2012 1:05:35 PM UTC-6, Boris wrote:
    My question is more about what's the best way to arrange package and type
    hierarchies with respect to Go's provided packages.
    I don't think there are type hierarchies. There is embedding and
    interfaces but not really hierarchies in the inheritance sense.
    Now package hierarchy is another matter that works similar to file system
    hierarchy, but stevewang gave you a link for that already.


    --
  • Steve McCoy at Nov 15, 2012 at 9:33 pm
    Sometimes all you need is a function. If you need a *time.Time in your
    function, make it a function parameter.

    On Thursday, November 15, 2012 1:28:38 PM UTC-5, Boris wrote:

    I am building some functionality that seems to fit best in the existing Go
    packages. For a very simple example related to a previous thread I started,
    where I need to sleep till pretty close to the boundary of the next N
    seconds into the future,

    func DurationTillBoundary(interval int64) time.Duration {
    now := time.Now()
    // This many ns till the next second boundary
    ns := time.Second.Nanoseconds() - int64(now.Nanosecond())
    // This many sec till the next desired seconds
    sec := interval - (now.Unix() % interval) - 1
    return time.Duration(sec * time.Second.Nanoseconds() + ns)*
    time.Nanosecond
    }

    That's what I wrote in my little throwaway script, but what I should have
    written, I believe, is

    func (t *time.Time) DurationTillBoundary(....

    This feels like it belongs in the time package in my own package
    hierarchy. Should I do that? That would effectively add onto the existing
    time package. Or maybe I should add a new time/timeutil package instead? Or
    should I root my package hierarchy like in Java, where I would do
    org.MyCompany.time instead? What are your experiences and what practices do
    you suggest? I expect that I will eventually have a very large codebase
    with probably hundreds of packages, so now is the best time for me to
    figure out how to do this.

    I have several other examples, such as container/fifo and some things that
    ought to go into math or mathutil.

    Thanks
    Boris
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 15, '12 at 6:28p
activeNov 15, '12 at 9:33p
posts7
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase