FAQ
When a constructor (function) returns a pointer of a struct (or other
nullable type like an interface), it is usually named like NewXXX, and
there is also a builtin function new that returns a pointer, so their names
are consistent. The word "new" usually implies that an allocation happens
and it needs a pointer (or interface) to point to the allocated space, and
the pointer (interface) itself could be nil.

But what if the constructor does not return a pointer but a struct itself?
Should I also name it as NewXXX? or MakeXXX? or anything else?

Hǎiliàng

--
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

  • Dave Cheney at Nov 26, 2013 at 2:25 am

    On Tue, Nov 26, 2013 at 1:22 PM, Hǎiliàng wrote:
    When a constructor (function) returns a pointer of a struct (or other
    nullable type like an interface), it is usually named like NewXXX, and there
    is also a builtin function new that returns a pointer, so their names are
    consistent. The word "new" usually implies that an allocation happens and it
    needs a pointer (or interface) to point to the allocated space, and the
    pointer (interface) itself could be nil.
    If you free yourself from the notion that New implies allocation, and
    embrace the idea that New returns a new thing for you to use, that
    would solve the problem, right ?
    But what if the constructor does not return a pointer but a struct itself?
    Should I also name it as NewXXX? or MakeXXX? or anything else?

    Hǎiliàng

    --
    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.
    --
    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.
  • Hailiang Wang at Nov 26, 2013 at 2:39 am
    The key point is: Go has two builtin functions: new and make. Function
    new is pure allocation but make does initialization after allocation.
    If all the constructors in the Go standard library are named MakeXXX,
    then there is no confusion: "new" stands for pure allocation and the
    constructor should always be named as MakeXXX for the extra
    initialization. However, all the constructors in the standard library
    are named as NewXXX, that's where the confusion comes.

    But anyway, probably I should always name a constructor as NewXXX and
    stops thinking about the inconsistency with "new", "make" builtin
    functions.

    Hǎiliàng


    On Tue, Nov 26, 2013 at 10:25 AM, Dave Cheney wrote:
    On Tue, Nov 26, 2013 at 1:22 PM, Hǎiliàng wrote:
    When a constructor (function) returns a pointer of a struct (or other
    nullable type like an interface), it is usually named like NewXXX, and there
    is also a builtin function new that returns a pointer, so their names are
    consistent. The word "new" usually implies that an allocation happens and it
    needs a pointer (or interface) to point to the allocated space, and the
    pointer (interface) itself could be nil.
    If you free yourself from the notion that New implies allocation, and
    embrace the idea that New returns a new thing for you to use, that
    would solve the problem, right ?
    But what if the constructor does not return a pointer but a struct itself?
    Should I also name it as NewXXX? or MakeXXX? or anything else?

    Hǎiliàng

    --
    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.
    --
    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.
  • Jesse McNelis at Nov 26, 2013 at 2:46 am

    On Tue, Nov 26, 2013 at 1:39 PM, Hailiang Wang wrote:

    The key point is: Go has two builtin functions: new and make. Function
    new is pure allocation but make does initialization after allocation.
    If all the constructors in the Go standard library are named MakeXXX,
    then there is no confusion: "new" stands for pure allocation and the
    constructor should always be named as MakeXXX for the extra
    initialization. However, all the constructors in the standard library
    are named as NewXXX, that's where the confusion comes.
    Many constructors aren't named NewXXX() because it's common for the purpose
    of the construction to be important and the construction itself to be
    rather irrelevant.
    Examples include:
    time.Date()
    time.Parse()
    time.Unix()
    net.Dial()
    http.FileServer()
    exec.Command()
    reflect.TypeOf()
    reflect.ValueOf()

    This is one of the reasons not to have constructors in the language because
    generally the fact that's you're creating a data structure isn't as
    important as why.

    --
    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.
  • Kevin Gillette at Nov 26, 2013 at 5:36 pm

    On Monday, November 25, 2013 7:46:03 PM UTC-7, Jesse McNelis wrote:
    Many constructors aren't named NewXXX() because it's common for the
    purpose of the construction to be important and the construction itself to
    be rather irrelevant.
    Examples include:
    time.Date()
    time.Parse()
    time.Unix()
    Good example! The "New" forms of these might have respectively been
    NewFromTimeParts, NewFromString, NewFromUnixTimeStamp. The problem with
    adding more to a name is that doing so often demands even a further
    sacrifice of conciseness (if it's long, it might as well be even longer).
    New doesn't really add anything here, since the time package makes it
    pretty clear that all functions produce either a Time, a Duration, or a
    Location.

    net.Dial()
    http.FileServer()
    exec.Command()
    reflect.TypeOf()
    reflect.ValueOf()
    os.Open
    os.Create
    os.OpenFile

    In line with Jesse's reasoning, I find that New is often useful when the
    'why' is obvious but the 'how' is not (when the zero value(s) of the type
    or some of its unexported fields aren't usable). Many single-type-centric
    packages have a function named exactly "New" for that purpose.

    --
    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
postedNov 26, '13 at 2:22a
activeNov 26, '13 at 5:36p
posts5
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase