FAQ
So, does anybody think that most of the go library, including the built-in
packages, are kinda use interface{} too often?

I take parser.ParseFile (in go/parser package) as an example, which was
recently used by myself. The function signature is:

func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
Mode) (f *ast.File, err error)


The src argument is defined with type interface{}. From the document, its
type could be string, []byte, or io.Reader.

Here, the largest problem is that the compile cannot help anything with
assuring src is of one of the above three types. In case, io.Reader
changes, or some change in the caller side that makes the implementation
doesn't satifiy io.Reader, the compler will never complain. We have to find
the problem on runtime(testcases or online service).

I think we can make it much better.

One proposal is to introduce the union of types. The grammar is like this

func ParseFile(fset *token.FileSet, filename string, src
string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


The compiler will check the following things:

    - In the caller side, the value given to src shoud be assignable to
    either of the type.
    - Inside the function, src can be only asserted as one of the types or a
    type one of the delcared type can be converted to.

I'm open with details like

    - The final grammar other than type | type | ...
    - one can define a named type like this: type SourceType
    string|[]byte|io.Reader

This can also be considered as a better alternative to function
overloading, which is not introduced in Go.

Any discussion is welcome!

Thanks!


--
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/d/optout.

Search Discussions

  • Daniel Skinner at Sep 10, 2014 at 4:05 pm
    seems like if anything it should just be an io.Reader the implementer
    should just strings.NewReader(theirString) to pass it along.
    On Wed, Sep 10, 2014 at 10:51 AM, David DENG wrote:

    So, does anybody think that most of the go library, including the built-in
    packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
    Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document, its
    type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader
    changes, or some change in the caller side that makes the implementation
    doesn't satifiy io.Reader, the compler will never complain. We have to
    find the problem on runtime(testcases or online service).

    I think we can make it much better.

    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


    The compiler will check the following things:

    - In the caller side, the value given to src shoud be assignable to
    either of the type.
    - Inside the function, src can be only asserted as one of the types or
    a type one of the delcared type can be converted to.

    I'm open with details like

    - The final grammar other than type | type | ...
    - one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function
    overloading, which is not introduced in Go.

    Any discussion is welcome!

    Thanks!


    --
    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/d/optout.
    --
    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/d/optout.
  • Kevin Gillette at Sep 12, 2014 at 7:33 am
    Agreed.
    On Wednesday, September 10, 2014 10:05:28 AM UTC-6, Daniel Skinner wrote:

    seems like if anything it should just be an io.Reader the implementer
    should just strings.NewReader(theirString) to pass it along.

    On Wed, Sep 10, 2014 at 10:51 AM, David DENG <david...@gmail.com
    <javascript:>> wrote:
    So, does anybody think that most of the go library, including the
    built-in packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{},
    mode Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document,
    its type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader
    changes, or some change in the caller side that makes the implementation
    doesn't satifiy io.Reader, the compler will never complain. We have to
    find the problem on runtime(testcases or online service).

    I think we can make it much better.

    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


    The compiler will check the following things:

    - In the caller side, the value given to src shoud be assignable to
    either of the type.
    - Inside the function, src can be only asserted as one of the types
    or a type one of the delcared type can be converted to.

    I'm open with details like

    - The final grammar other than type | type | ...
    - one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function
    overloading, which is not introduced in Go.

    Any discussion is welcome!

    Thanks!


    --
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.
    --
    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/d/optout.
  • Andy Balholm at Sep 10, 2014 at 6:28 pm
    http://golang.org/doc/faq#variant_types

    I still think variant types might be a good idea if they had exactly the same semantics as the empty interface, except for stricter type checking. But it's not going to happen, and I'm OK with that.

    But variant types wouldn't really solve the problem. Most of the places where interface{} is used actually do have some constraint on the type that is used. (Functions that don't care at all what their parameters are are pretty rare.) Variant types would allow the constraints to be specified in some cases. But others have a set of acceptable types that is open-ended, yet constrained. The database/sql Scan methods, for example, require pointers (except that you could create a type that fulfills Scanner on a value receiver). Some pointer types work, some don't. Should there be some way to spell out exactly which pointer types are acceptable, and which are not? In theory, yes, but if you want to cover all the possible cases, you'd probably need a Turing-complete type system. Go doesn't want to be that kind of language. So we'd be stuck with interface{} for a lot of cases anyway.

    --
    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/d/optout.
  • Egon at Sep 11, 2014 at 7:13 am

    On Wednesday, 10 September 2014 18:51:34 UTC+3, David DENG wrote:
    So, does anybody think that most of the go library, including the built-in
    packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
    Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document, its
    type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader
    changes, or some change in the caller side that makes the implementation
    doesn't satifiy io.Reader, the compler will never complain. We have to
    find the problem on runtime(testcases or online service).

    I think we can make it much better.
    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)

    There's a simpler solution:

    func ParseFile(fset *token.FileSet, filename string, src io.Reader, mode
    Mode) (f *ast.File, err error)

    But it cannot be changed due to compatibility guarantee.

    The compiler will check the following things:

    - In the caller side, the value given to src shoud be assignable to
    either of the type.
    - Inside the function, src can be only asserted as one of the types or
    a type one of the delcared type can be converted to.

    I'm open with details like

    - The final grammar other than type | type | ...
    - one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function
    overloading, which is not introduced in Go.

    Any discussion is welcome!

    Thanks!

    --
    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/d/optout.
  • Andrewchamberss at Sep 12, 2014 at 12:11 am
    I don't see why a reader cant just be used and people can provide their own
    convenience wrappers. Otherwise why not just have 3 different function
    ParseFile ParseBytes ParseReader
    On Thursday, September 11, 2014 7:12:59 PM UTC+12, egon wrote:


    On Wednesday, 10 September 2014 18:51:34 UTC+3, David DENG wrote:

    So, does anybody think that most of the go library, including the
    built-in packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{},
    mode Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document,
    its type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader
    changes, or some change in the caller side that makes the implementation
    doesn't satifiy io.Reader, the compler will never complain. We have to
    find the problem on runtime(testcases or online service).

    I think we can make it much better.
    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)

    There's a simpler solution:

    func ParseFile(fset *token.FileSet, filename string, src io.Reader, mode
    Mode) (f *ast.File, err error)

    But it cannot be changed due to compatibility guarantee.

    The compiler will check the following things:

    - In the caller side, the value given to src shoud be assignable to
    either of the type.
    - Inside the function, src can be only asserted as one of the types
    or a type one of the delcared type can be converted to.

    I'm open with details like

    - The final grammar other than type | type | ...
    - one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function
    overloading, which is not introduced in Go.

    Any discussion is welcome!

    Thanks!

    --
    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/d/optout.
  • Tahir at Sep 12, 2014 at 1:02 am
    There is no need for a new Kind such as union types since you can define a
    type by embedding other types.

    Would be then quite easy to create a ParseFile wrapper which would take an
    object of this new type as argument.
    On Wednesday, September 10, 2014 4:51:34 PM UTC+1, David DENG wrote:

    So, does anybody think that most of the go library, including the built-in
    packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
    Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document, its
    type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader
    changes, or some change in the caller side that makes the implementation
    doesn't satifiy io.Reader, the compler will never complain. We have to
    find the problem on runtime(testcases or online service).

    I think we can make it much better.

    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


    The compiler will check the following things:

    - In the caller side, the value given to src shoud be assignable to
    either of the type.
    - Inside the function, src can be only asserted as one of the types or
    a type one of the delcared type can be converted to.

    I'm open with details like

    - The final grammar other than type | type | ...
    - one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function
    overloading, which is not introduced in Go.

    Any discussion is welcome!

    Thanks!

    --
    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/d/optout.
  • Roger peppe at Sep 12, 2014 at 9:12 am
    In this case, I agree. As ParseFile always reads all of the data,
    the argument should probably be just []byte.

    On 10 September 2014 16:51, David DENG wrote:
    So, does anybody think that most of the go library, including the built-in
    packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
    Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document, its
    type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader changes,
    or some change in the caller side that makes the implementation doesn't
    satifiy io.Reader, the compler will never complain. We have to find the
    problem on runtime(testcases or online service).

    I think we can make it much better.

    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


    The compiler will check the following things:

    In the caller side, the value given to src shoud be assignable to either of
    the type.
    Inside the function, src can be only asserted as one of the types or a type
    one of the delcared type can be converted to.

    I'm open with details like

    The final grammar other than type | type | ...
    one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function overloading,
    which is not introduced in Go.

    Any discussion is welcome!

    Thanks!


    --
    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/d/optout.
    --
    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/d/optout.
  • Hariharan Srinath at Sep 12, 2014 at 9:25 am
    Method overloading would be the standard solution in other languages for
    situations like this. However the FAQ says "Experience with other languages
    told us that having a variety of methods with the same name but different
    signatures was occasionally useful but that it could also be confusing and
    fragile in practice"

    I'm curious to understand more about trade-offs that prompted this choice
    since in cases like this kind of use of interface{}, the choice pushes what
    could have been a compile time check to a runtime check with equal or more
    confusion/fragility implications.

    Regards
    Srinath
    On Wednesday, September 10, 2014 9:21:34 PM UTC+5:30, David DENG wrote:

    So, does anybody think that most of the go library, including the built-in
    packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
    Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document, its
    type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader
    changes, or some change in the caller side that makes the implementation
    doesn't satifiy io.Reader, the compler will never complain. We have to
    find the problem on runtime(testcases or online service).

    I think we can make it much better.

    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


    The compiler will check the following things:

    - In the caller side, the value given to src shoud be assignable to
    either of the type.
    - Inside the function, src can be only asserted as one of the types or
    a type one of the delcared type can be converted to.

    I'm open with details like

    - The final grammar other than type | type | ...
    - one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function
    overloading, which is not introduced in Go.

    Any discussion is welcome!

    Thanks!

    --
    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/d/optout.
  • Roger peppe at Sep 12, 2014 at 9:49 am

    On 12 September 2014 10:25, Hariharan Srinath wrote:
    Method overloading would be the standard solution in other languages for
    situations like this. However the FAQ says "Experience with other languages
    told us that having a variety of methods with the same name but different
    signatures was occasionally useful but that it could also be confusing and
    fragile in practice"

    I'm curious to understand more about trade-offs that prompted this choice
    since in cases like this kind of use of interface{}, the choice pushes what
    could have been a compile time check to a runtime check with equal or more
    confusion/fragility implications.
    I think this was just a matter of inexperience. This API was implemented
    quite early on, and I seem to remember the author (Robert Griesemer?)
    saying that he would have done it differently if he was doing it again.

    Are there any other cases like this in the standard library? I can't
    think of any off the top of my head.
    Regards
    Srinath

    On Wednesday, September 10, 2014 9:21:34 PM UTC+5:30, David DENG wrote:

    So, does anybody think that most of the go library, including the built-in
    packages, are kinda use interface{} too often?

    I take parser.ParseFile (in go/parser package) as an example, which was
    recently used by myself. The function signature is:

    func ParseFile(fset *token.FileSet, filename string, src interface{}, mode
    Mode) (f *ast.File, err error)


    The src argument is defined with type interface{}. From the document, its
    type could be string, []byte, or io.Reader.

    Here, the largest problem is that the compile cannot help anything with
    assuring src is of one of the above three types. In case, io.Reader changes,
    or some change in the caller side that makes the implementation doesn't
    satifiy io.Reader, the compler will never complain. We have to find the
    problem on runtime(testcases or online service).

    I think we can make it much better.

    One proposal is to introduce the union of types. The grammar is like this

    func ParseFile(fset *token.FileSet, filename string, src
    string|[]byte|io.Reader, mode Mode) (f *ast.File, err error)


    The compiler will check the following things:

    In the caller side, the value given to src shoud be assignable to either
    of the type.
    Inside the function, src can be only asserted as one of the types or a
    type one of the delcared type can be converted to.

    I'm open with details like

    The final grammar other than type | type | ...
    one can define a named type like this: type SourceType
    string|[]byte|io.Reader

    This can also be considered as a better alternative to function
    overloading, which is not introduced in Go.

    Any discussion is welcome!

    Thanks!
    --
    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/d/optout.
    --
    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/d/optout.
  • Benjamin Measures at Sep 13, 2014 at 8:54 am
    I think this was just a matter of inexperience.
    Given the context, your suggestion of inexperience is easily misunderstood.

    --
    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/d/optout.
  • Andrew Gerrand at Sep 15, 2014 at 11:25 pm

    On 13 September 2014 18:54, Benjamin Measures wrote:

    I think this was just a matter of inexperience.
    Given the context, your suggestion of inexperience is easily misunderstood.
    By whom? Robert readily admits that in retrospect he would have done things
    differently. When these packages were authored we were all still learning
    Go (as we still are, today).

    When we were preparing for Go 1 we reviewed all the APIs and made a lot of
    improvements. We missed this one, and a few others too. I think we did a
    good job overall, though.

    I don't think this particular API causes real problems, though. You might
    make the mistake once, but it's not going to be a subtle error when you do.

    Andrew

    --
    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/d/optout.
  • Eduard Castany at Sep 15, 2014 at 11:39 pm
    If you realize things could have been done better, why not add/grow
    functionality and mark the old one as deprecated? I would prefer that
    rather than wait for Go 2...

    El dimarts 16 de setembre de 2014 1:25:54 UTC+2, Andrew Gerrand va escriure:


    On 13 September 2014 18:54, Benjamin Measures <saint....@gmail.com
    <javascript:>> wrote:
    I think this was just a matter of inexperience.
    Given the context, your suggestion of inexperience is easily
    misunderstood.
    By whom? Robert readily admits that in retrospect he would have done
    things differently. When these packages were authored we were all still
    learning Go (as we still are, today).

    When we were preparing for Go 1 we reviewed all the APIs and made a lot of
    improvements. We missed this one, and a few others too. I think we did a
    good job overall, though.

    I don't think this particular API causes real problems, though. You might
    make the mistake once, but it's not going to be a subtle error when you do.

    Andrew
    --
    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/d/optout.
  • Andrew Gerrand at Sep 16, 2014 at 1:57 am

    On 16 September 2014 09:39, Eduard Castany wrote:

    If you realize things could have been done better, why not add/grow
    functionality and mark the old one as deprecated? I would prefer that
    rather than wait for Go 2...

    We have, in isolated cases. For example, the zip.FileHeader struct has the
    fields CompressedSize and UncompressedSize that are marked as deprecated in
    favour of CompressedSize64 and UncompressedSize64.

    But such changes need to be worth the clutter and confusion. The motivating
    example of this thread doesn't seem worth addressing, to me.

    Andrew

    --
    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/d/optout.
  • Benjamin Measures at Sep 16, 2014 at 9:02 am

    On Tuesday, 16 September 2014 00:25:54 UTC+1, Andrew Gerrand wrote:
    By whom? Robert readily admits that in retrospect he would have done
    things differently.

    The context was in reply to the following post:
    On Friday, 12 September 2014 10:25:00 UTC+1, Hariharan Srinath wrote:

    Method overloading would be the standard solution in other languages for
    situations like this. However the FAQ says "Experience with other languages
    told us that having a variety of methods with the same name but different
    signatures was occasionally useful but that it could also be confusing and
    fragile in practice"

    I'm curious to understand more about trade-offs that prompted this choice
    since in cases like this kind of use of interface{}, the choice pushes what
    could have been a compile time check to a runtime check with equal or more
    confusion/fragility implications.
    My view is "this choice" refers to the experience-based choice of
    simplifying method dispatch, where it could otherwise have been "solved" by
    adding overloaded methods. Given this meaning, to reply with:
    On Friday, 12 September 2014 10:49:35 UTC+1, rog wrote:

    I think this was just a matter of inexperience. This API was implemented
    quite early on, and I seem to remember the author (Robert Griesemer?)
    saying that he would have done it differently if he was doing it again.
    may be mis-interpreted as this choice being a point of inexperience and
    regret. It is, afaik, not.

    On Tuesday, 16 September 2014 00:25:54 UTC+1, Andrew Gerrand wrote:

    When we were preparing for Go 1 we reviewed all the APIs and made a lot of
    improvements. We missed this one, and a few others too. I think we did a
    good job overall, though.
    Agreed.

    --
    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/d/optout.
  • Roger peppe at Sep 16, 2014 at 9:45 am

    On 16 September 2014 10:02, Benjamin Measures wrote:
    On Tuesday, 16 September 2014 00:25:54 UTC+1, Andrew Gerrand wrote:

    By whom? Robert readily admits that in retrospect he would have done
    things differently.


    The context was in reply to the following post:
    On Friday, 12 September 2014 10:25:00 UTC+1, Hariharan Srinath wrote:

    Method overloading would be the standard solution in other languages for
    situations like this. However the FAQ says "Experience with other languages
    told us that having a variety of methods with the same name but different
    signatures was occasionally useful but that it could also be confusing and
    fragile in practice"

    I'm curious to understand more about trade-offs that prompted this choice
    since in cases like this kind of use of interface{}, the choice pushes what
    could have been a compile time check to a runtime check with equal or more
    confusion/fragility implications.

    My view is "this choice" refers to the experience-based choice of
    simplifying method dispatch, where it could otherwise have been "solved" by
    adding overloaded methods. Given this meaning, to reply with:
    On Friday, 12 September 2014 10:49:35 UTC+1, rog wrote:

    I think this was just a matter of inexperience. This API was implemented
    quite early on, and I seem to remember the author (Robert Griesemer?)
    saying that he would have done it differently if he was doing it again.

    may be mis-interpreted as this choice being a point of inexperience and
    regret. It is, afaik, not.
    Yes, I was talking entirely about go/parser, not the choice to
    avoid method overloading in the language. Sorry if that wasn't clear.

       cheers,
         rog.

    --
    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/d/optout.
  • David DENG at Sep 16, 2014 at 12:55 pm
    I think no doubt the Go dev team did do a good job! That's also part of the
    reason why I love Go.

    But how this API will be redesigned with current syntax? Split into several
    functions? or only support io.Reader?

    ps: I roughly checked other functions of the builtin packages, didn't find
    another example of the same type. One related is io.Copy. According to the
    documents, it will call WriteTo or ReadFrom when possible. But that is not
    protected by compiler as well.

    David
    On Monday, September 15, 2014 4:25:54 PM UTC-7, Andrew Gerrand wrote:



    On 13 September 2014 18:54, Benjamin Measures <saint....@gmail.com
    <javascript:>> wrote:
    I think this was just a matter of inexperience.
    Given the context, your suggestion of inexperience is easily
    misunderstood.
    By whom? Robert readily admits that in retrospect he would have done
    things differently. When these packages were authored we were all still
    learning Go (as we still are, today).

    When we were preparing for Go 1 we reviewed all the APIs and made a lot of
    improvements. We missed this one, and a few others too. I think we did a
    good job overall, though.

    I don't think this particular API causes real problems, though. You might
    make the mistake once, but it's not going to be a subtle error when you do.

    Andrew
    --
    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/d/optout.
  • Roger peppe at Sep 16, 2014 at 1:11 pm

    On 16 September 2014 13:55, David DENG wrote:
    I think no doubt the Go dev team did do a good job! That's also part of the
    reason why I love Go.

    But how this API will be redesigned with current syntax? Split into several
    functions? or only support io.Reader?
    As I said earlier, I'd suggest only supporting []byte, as that's what
    gets used under the covers. There are existing functions to convert to
    []byte (e.g. ioutil.ReadAll).

    The lack of method overloading creates a pressure to define methods in
    terms of a single general type rather than creating convenience methods
    for many types. I consider this a good thing - convenience methods for
    converting to the general type can be implemented independently of the
    method itself, and are often potentially independently useful.

       cheers,
         rog.

    --
    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/d/optout.
  • Gustavo Niemeyer at Sep 16, 2014 at 6:22 pm

    On Tue, Sep 16, 2014 at 10:11 AM, roger peppe wrote:
    As I said earlier, I'd suggest only supporting []byte, as that's what
    gets used under the covers. There are existing functions to convert to
    []byte (e.g. ioutil.ReadAll).
    In the interest of us all having better APIs for packages in general,
    it seems that the fact that the whole content is read in memory
    _today_ should not be used as a deciding factor to use []byte rather
    than io.Reader.

    Instead, I usually consider two points when designing such APIs:

    1. Will the data be in memory most of the time as a []byte anyway?

    The answer here seems to be no, this will often come from a file,
    which is an io.Reader.

    2. Is it critical to have all the data in memory at once for the
    algorithm at hand, or does it make sense to have a streaming API at
    some point?

    The answer here might be yes.

    So, my personal choice would have been an io.Reader.


    gustavo @ http://niemeyer.net

    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 10, '14 at 3:52p
activeSep 16, '14 at 6:22p
posts19
users13
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase