FAQ
Hi all,

I've experimented with code generation as a way to avoid code repetition,
in the particular case of functions which apart from the parameter types
would be identical, like these :

http://play.golang.org/p/Vuhb1Gb_n3

I quite like that the above code is compilable and (with some effort)
unit-testable go-code. But simlpy using gofmt to replace ANY and ANY_2 with
a specific type (except in the type statements, which can be put in a
separate not translated file) I get specialized versions for free.

Well, almost free ... I have to add a Makefile to handle automatic
translation ( and I hate makefiles ... ) but apart from that it seems a
nice enough approach.

Now, I'm just evaluating Go for possible usage in the future, so I'd like
to know if people using go for real find this approach useful, workable or
Simply Just A Bad Idea ...

thanks in advance
-------
FB



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

  • Kevin Gillette at Dec 9, 2013 at 7:56 pm
    Since the go compiler intentionally does not have any preprocessor support
    (and no support for configurable build steps), then any kind of "easy" path
    to code generation would have to be done via a 3rd party tool. The core
    developers, and at least much of the seasoned community members, are of the
    general opinion that code generation is okay, as long as the programmers
    using a given library/application don't have to know about it. This means
    that code generation is fine during development, but not as part of the
    build.

    If I were to write a tool to assist in code generation, particularly to
    graft some form of parametric polymorphism onto the language, I would do
    the following:

    package polygen

    // T may only be used in type declarations.
    type T AnyType

    // AnyType is intentionally left undefined, so that
    // polygen can't be used in a normal build process


    package mylib

    import "wherever.com/polygen"

    type Type polygen.T

    func Sum(s []Type) int {
         var sum int
         for _, v := range s {
             sum += int(v)
         }
         return sum
    }

    There would then be a corresponding tool, with the invocations `polygen
    int8` and `polygen Type=int8` being equivalent, producing:

    package mylib

    // import and polymorphic type declarations removed

    func Sum(s []int8) int {
         var sum int
         for _, v := range s {
             sum += int(v)
         }
         return sum
    }

    The generated form is what would be published for user consumption.
    On Monday, December 9, 2013 10:51:29 AM UTC-7, Francesco Bochicchio wrote:

    Hi all,

    I've experimented with code generation as a way to avoid code repetition,
    in the particular case of functions which apart from the parameter types
    would be identical, like these :

    http://play.golang.org/p/Vuhb1Gb_n3

    I quite like that the above code is compilable and (with some effort)
    unit-testable go-code. But simlpy using gofmt to replace ANY and ANY_2 with
    a specific type (except in the type statements, which can be put in a
    separate not translated file) I get specialized versions for free.

    Well, almost free ... I have to add a Makefile to handle automatic
    translation ( and I hate makefiles ... ) but apart from that it seems a
    nice enough approach.

    Now, I'm just evaluating Go for possible usage in the future, so I'd like
    to know if people using go for real find this approach useful, workable or
    Simply Just A Bad Idea ...

    thanks in advance
    -------
    FB

    --
    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.
  • Matt Sherman at Dec 10, 2013 at 4:10 am
    Mentioned in an earlier thread, I'm developing a codegen tool along these
    lines, specifically for structs: http://clipperhouse.github.io/gen/

    I'm thinking about primitives as well (as in your example), not sure what
    approach to take just yet.
    On Monday, December 9, 2013 2:56:25 PM UTC-5, Kevin Gillette wrote:

    Since the go compiler intentionally does not have any preprocessor support
    (and no support for configurable build steps), then any kind of "easy" path
    to code generation would have to be done via a 3rd party tool. The core
    developers, and at least much of the seasoned community members, are of the
    general opinion that code generation is okay, as long as the programmers
    using a given library/application don't have to know about it. This means
    that code generation is fine during development, but not as part of the
    build.

    If I were to write a tool to assist in code generation, particularly to
    graft some form of parametric polymorphism onto the language, I would do
    the following:

    package polygen

    // T may only be used in type declarations.
    type T AnyType

    // AnyType is intentionally left undefined, so that
    // polygen can't be used in a normal build process


    package mylib

    import "wherever.com/polygen"

    type Type polygen.T

    func Sum(s []Type) int {
    var sum int
    for _, v := range s {
    sum += int(v)
    }
    return sum
    }

    There would then be a corresponding tool, with the invocations `polygen
    int8` and `polygen Type=int8` being equivalent, producing:

    package mylib

    // import and polymorphic type declarations removed

    func Sum(s []int8) int {
    var sum int
    for _, v := range s {
    sum += int(v)
    }
    return sum
    }

    The generated form is what would be published for user consumption.
    On Monday, December 9, 2013 10:51:29 AM UTC-7, Francesco Bochicchio wrote:

    Hi all,

    I've experimented with code generation as a way to avoid code repetition,
    in the particular case of functions which apart from the parameter types
    would be identical, like these :

    http://play.golang.org/p/Vuhb1Gb_n3

    I quite like that the above code is compilable and (with some effort)
    unit-testable go-code. But simlpy using gofmt to replace ANY and ANY_2 with
    a specific type (except in the type statements, which can be put in a
    separate not translated file) I get specialized versions for free.

    Well, almost free ... I have to add a Makefile to handle automatic
    translation ( and I hate makefiles ... ) but apart from that it seems a
    nice enough approach.

    Now, I'm just evaluating Go for possible usage in the future, so I'd like
    to know if people using go for real find this approach useful, workable or
    Simply Just A Bad Idea ...

    thanks in advance
    -------
    FB

    --
    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 Dec 10, 2013 at 8:05 am
    That one struck me as being purpose designed for slices of that that are
    intended to be stream processed/filtered, adding manipulation methods to
    the provided concrete types.
    On Monday, December 9, 2013 9:10:46 PM UTC-7, Matt Sherman wrote:

    Mentioned in an earlier thread, I'm developing a codegen tool along these
    lines, specifically for structs: http://clipperhouse.github.io/gen/

    I'm thinking about primitives as well (as in your example), not sure what
    approach to take just yet.
    On Monday, December 9, 2013 2:56:25 PM UTC-5, Kevin Gillette wrote:

    Since the go compiler intentionally does not have any preprocessor
    support (and no support for configurable build steps), then any kind of
    "easy" path to code generation would have to be done via a 3rd party tool.
    The core developers, and at least much of the seasoned community members,
    are of the general opinion that code generation is okay, as long as the
    programmers using a given library/application don't have to know about it.
    This means that code generation is fine during development, but not as part
    of the build.

    If I were to write a tool to assist in code generation, particularly to
    graft some form of parametric polymorphism onto the language, I would do
    the following:

    package polygen

    // T may only be used in type declarations.
    type T AnyType

    // AnyType is intentionally left undefined, so that
    // polygen can't be used in a normal build process


    package mylib

    import "wherever.com/polygen"

    type Type polygen.T

    func Sum(s []Type) int {
    var sum int
    for _, v := range s {
    sum += int(v)
    }
    return sum
    }

    There would then be a corresponding tool, with the invocations `polygen
    int8` and `polygen Type=int8` being equivalent, producing:

    package mylib

    // import and polymorphic type declarations removed

    func Sum(s []int8) int {
    var sum int
    for _, v := range s {
    sum += int(v)
    }
    return sum
    }

    The generated form is what would be published for user consumption.
    On Monday, December 9, 2013 10:51:29 AM UTC-7, Francesco Bochicchio wrote:

    Hi all,

    I've experimented with code generation as a way to avoid code
    repetition, in the particular case of functions which apart from the
    parameter types would be identical, like these :

    http://play.golang.org/p/Vuhb1Gb_n3

    I quite like that the above code is compilable and (with some effort)
    unit-testable go-code. But simlpy using gofmt to replace ANY and ANY_2 with
    a specific type (except in the type statements, which can be put in a
    separate not translated file) I get specialized versions for free.

    Well, almost free ... I have to add a Makefile to handle automatic
    translation ( and I hate makefiles ... ) but apart from that it seems a
    nice enough approach.

    Now, I'm just evaluating Go for possible usage in the future, so I'd
    like to know if people using go for real find this approach useful,
    workable or Simply Just A Bad Idea ...

    thanks in advance
    -------
    FB

    --
    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.
  • Francesco Bochicchio at Dec 10, 2013 at 9:34 am
    I agree that the generated code shall be readable and shall be the only
    code used by library users, and that the "template" code shall be only used
    by library developers. However, I thing that it is of some value the fact
    that the "template" code is by itself plain go gode and can be at least
    compiled, it makes easier to write/modify them ( unit-testing like I did
    in my example requires too much trouble in converting parameters and
    especially functions and I think it is better to unit-test the generated
    code anyway ).



    Il giorno lunedì 9 dicembre 2013 20:56:25 UTC+1, Kevin Gillette ha scritto:
    Since the go compiler intentionally does not have any preprocessor support
    (and no support for configurable build steps), then any kind of "easy" path
    to code generation would have to be done via a 3rd party tool. The core
    developers, and at least much of the seasoned community members, are of the
    general opinion that code generation is okay, as long as the programmers
    using a given library/application don't have to know about it. This means
    that code generation is fine during development, but not as part of the
    build.

    If I were to write a tool to assist in code generation, particularly to
    graft some form of parametric polymorphism onto the language, I would do
    the following:

    package polygen

    // T may only be used in type declarations.
    type T AnyType

    // AnyType is intentionally left undefined, so that
    // polygen can't be used in a normal build process


    package mylib

    import "wherever.com/polygen"

    type Type polygen.T

    func Sum(s []Type) int {
    var sum int
    for _, v := range s {
    sum += int(v)
    }
    return sum
    }

    There would then be a corresponding tool, with the invocations `polygen
    int8` and `polygen Type=int8` being equivalent, producing:

    package mylib

    // import and polymorphic type declarations removed

    func Sum(s []int8) int {
    var sum int
    for _, v := range s {
    sum += int(v)
    }
    return sum
    }

    The generated form is what would be published for user consumption.

    --
    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
postedDec 9, '13 at 5:51p
activeDec 10, '13 at 9:34a
posts5
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase