FAQ
Based on my understanding it is a common practice for structs that require
some sort initialization of private members, is that they have some sort of
new function. Assuming the struct needed to have some sort of method called
by the user to perform, wouldn't it just be nicer to implement lazy loading
in that method? Like sync.Once.

Example:

type Ex struct {

m map[string]string

once sync.Once

}

func (e *Ex) Run() {

e.once.Do(func() {


e.m = make(map[string]string)

})

// whatever else Run does

}

--
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Mortdeus at Jul 21, 2013 at 10:20 am
    This is confusing to me (which means its probably a bad idea to adopt as a
    go idiom as I definitely wont be the only one).
      How is your version different than my version?
    (http://play.golang.org/p/eQ786uuJWC)?
    On Sunday, July 21, 2013 3:01:42 AM UTC-5, otiu...@gmail.com wrote:

    Based on my understanding it is a common practice for structs that require
    some sort initialization of private members, is that they have some sort of
    new function. Assuming the struct needed to have some sort of method called
    by the user to perform, wouldn't it just be nicer to implement lazy loading
    in that method? Like sync.Once.

    Example:

    type Ex struct {

    m map[string]string

    once sync.Once

    }

    func (e *Ex) Run() {

    e.once.Do(func() {


    e.m = make(map[string]string)

    })

    // whatever else Run does

    }
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Arne Hormann at Jul 21, 2013 at 10:41 am

    On Sunday, July 21, 2013 3:01:42 AM UTC-5, otiu...@gmail.com wrote:
    Based on my understanding it is a common practice for structs that
    require some sort initialization of private members, is that they have some
    sort of new function. Assuming the struct needed to have some sort of
    method called by the user to perform, wouldn't it just be nicer to
    implement lazy loading in that method? Like sync.Once.

    Example:

    type Ex struct {

    m map[string]string

    once sync.Once

    }

    func (e *Ex) Run() {

    e.once.Do(func() {


    e.m = make(map[string]string)

    })

    // whatever else Run does

    }
    This one won't work - a pointer receiver can legally be called on nil and
    will crash as e.once doesn't exists.
    You can probably use that pattern for structs instead of struct pointers,
    but if it's more than one function, you have to copy the initialisation
    code everywhere - a rather bad idea.
    I would avoid that pattern.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Lars Seipel at Jul 21, 2013 at 2:36 pm

    On Sun, Jul 21, 2013 at 03:41:05AM -0700, Arne Hormann wrote:
    This one won't work - a pointer receiver can legally be called on nil
    Maybe from a language point of view but this doesn't mean it has to make
    sense for every type. Think about it: of what use would methods with
    pointer receivers be if they necessarily had to work with nil pointers?

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Arne Hormann at Jul 21, 2013 at 7:58 pm

    Am Sonntag, 21. Juli 2013 16:36:20 UTC+2 schrieb Lars Seipel:
    On Sun, Jul 21, 2013 at 03:41:05AM -0700, Arne Hormann wrote:
    This one won't work - a pointer receiver can legally be called on nil
    Maybe from a language point of view but this doesn't mean it has to make
    sense for every type. Think about it: of what use would methods with
    pointer receivers be if they necessarily had to work with nil pointers?
    You are right, but I'd still strive for a failsafe solution - esp. with a
    pattern created to help initialisation by avoiding a function for it and
    making it simpler.
    My main issue isn't the nil pointer case though, it's that the
    initialisation code would have to be copied to every function with this
    receiver - which is error prone and requires too much copy-pasting for my
    taste.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Otium Dev at Jul 21, 2013 at 3:11 pm
    I wasn't ware that they could be called with nil, thanks for the advice,
    and I definitely won't do this now.
    On Sunday, July 21, 2013 3:41:05 AM UTC-7, Arne Hormann wrote:

    On Sunday, July 21, 2013 3:01:42 AM UTC-5, otiu...@gmail.com wrote:

    Based on my understanding it is a common practice for structs that
    require some sort initialization of private members, is that they have some
    sort of new function. Assuming the struct needed to have some sort of
    method called by the user to perform, wouldn't it just be nicer to
    implement lazy loading in that method? Like sync.Once.

    Example:

    type Ex struct {

    m map[string]string

    once sync.Once

    }

    func (e *Ex) Run() {

    e.once.Do(func() {


    e.m = make(map[string]string)

    })

    // whatever else Run does

    }
    This one won't work - a pointer receiver can legally be called on nil and
    will crash as e.once doesn't exists.
    You can probably use that pattern for structs instead of struct pointers,
    but if it's more than one function, you have to copy the initialisation
    code everywhere - a rather bad idea.
    I would avoid that pattern.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Otium Dev at Jul 21, 2013 at 3:27 pm
    There is functionally no difference, except mine uses thread-safe code with
    the sync.Once, in this case it is not needed, I just did it out of habbit.
    On Sunday, July 21, 2013 3:19:58 AM UTC-7, mortdeus wrote:

    This is confusing to me (which means its probably a bad idea to adopt as a
    go idiom as I definitely wont be the only one).
    How is your version different than my version? (
    http://play.golang.org/p/eQ786uuJWC)?
    On Sunday, July 21, 2013 3:01:42 AM UTC-5, otiu...@gmail.com wrote:

    Based on my understanding it is a common practice for structs that
    require some sort initialization of private members, is that they have some
    sort of new function. Assuming the struct needed to have some sort of
    method called by the user to perform, wouldn't it just be nicer to
    implement lazy loading in that method? Like sync.Once.

    Example:

    type Ex struct {

    m map[string]string

    once sync.Once

    }

    func (e *Ex) Run() {

    e.once.Do(func() {


    e.m = make(map[string]string)

    })

    // whatever else Run does

    }
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 21, '13 at 8:01a
activeJul 21, '13 at 7:58p
posts7
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase