FAQ
Struct (field) tags have proven very useful, and I am curious whether there
has been consideration of offering the same at the type level? Would be
handy for the stuff I am doing on gen <https://github.com/clipperhouse/gen>.

Not sure where it would go syntactically, but something along the lines of:

type Thing struct `tag:"thing"`
{
     Field1 int `tag:"stuff"`
}

type Another []string `tag:"foo"`

A bit of metadata would go a long way. Could apply to any type def, not
just structs. Was there a particular design decision to only support struct
fields?

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

  • Rob Pike at Dec 4, 2013 at 3:54 pm
    Tags were put in to support transport metadata for structs, to avoid
    needed an external IDL for JSON, XML, protocol buffers and so on. They
    have indeed been useful but they also result in noisy-looking code and
    encourage a weak and clumsy kind of metaprogramming. It's telling that
    they're only visible through the reflection interface.

    I would be reluctant to extend their reach.

    -rob

    --
    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.
  • Gustavo Niemeyer at Dec 4, 2013 at 4:08 pm

    On Wed, Dec 4, 2013 at 1:03 PM, Matt Sherman wrote:
    Struct (field) tags have proven very useful, and I am curious whether there
    has been consideration of offering the same at the type level? Would be
    handy for the stuff I am doing on gen.

    Not sure where it would go syntactically, but something along the lines of:

    type Thing struct `tag:"thing"`
    If you're already parsing Go code, you can use comments for that kind of thing:

    //gen thing
    type Thing struct { ... }


    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/groups/opt_out.
  • Ugorji Nwoke at Dec 4, 2013 at 4:20 pm
    I had this same requirement for my codec library and I solved it by
    defining a private field within the struct and assigning tags to it. E.g.

    type Thing struct {
       __struct struct{} `tag:"thing"`
       Field1 int
    }

    This works well for me. It's unexported, so you don't lose anything.

    On Wednesday, December 4, 2013 10:03:04 AM UTC-5, Matt Sherman wrote:

    Struct (field) tags have proven very useful, and I am curious whether
    there has been consideration of offering the same at the type level? Would
    be handy for the stuff I am doing on gen<https://github.com/clipperhouse/gen>
    .

    Not sure where it would go syntactically, but something along the lines of:

    type Thing struct `tag:"thing"`
    {
    Field1 int `tag:"stuff"`
    }

    type Another []string `tag:"foo"`

    A bit of metadata would go a long way. Could apply to any type def, not
    just structs. Was there a particular design decision to only support struct
    fields?
    --
    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 4, 2013 at 6:28 pm
    Ugorji, that's an interesting approach, may try that.

    Rob, thanks for the explanation. Good point about arbitrary text morphing
    into a bad programming language.

    - Matt

    --
    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 5, 2013 at 5:20 am
    If we pretend that the proposal (and proposed syntax) were universally
    favored, it'd result in an inconsistent grammar. Consider:

    // the brace must go on the same line as the tag
    // unless a special (inconsistent) exception were made
    type Thing struct `tag:"thing"` {
    Field1 int `tag:"stuff"`
    }
    type Integer int `tag:"other thing"`

    In the above, the tag in the struct case goes after the struct keyword. For
    primitive types, it'd Go after the type definition. Really, the only
    consistent approach is to put the tag after the entire type definition, and
    that'd result in:

    type Thing struct {
    Field1 int `tag:"stuff"`
    } `tag:"thing"`

    That looks a bit like typedef's in C, and typedef'd structs are pretty ugly.
    On Wednesday, December 4, 2013 8:03:04 AM UTC-7, Matt Sherman wrote:

    Struct (field) tags have proven very useful, and I am curious whether
    there has been consideration of offering the same at the type level? Would
    be handy for the stuff I am doing on gen<https://github.com/clipperhouse/gen>
    .

    Not sure where it would go syntactically, but something along the lines of:

    type Thing struct `tag:"thing"`
    {
    Field1 int `tag:"stuff"`
    }

    type Another []string `tag:"foo"`

    A bit of metadata would go a long way. Could apply to any type def, not
    just structs. Was there a particular design decision to only support struct
    fields?
    --
    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 9, 2013 at 1:00 am
    I went with the comment approach here, seems to
    work: http://clipperhouse.github.io/gen/#Subsetting
    On Thursday, December 5, 2013 12:20:37 AM UTC-5, Kevin Gillette wrote:

    If we pretend that the proposal (and proposed syntax) were universally
    favored, it'd result in an inconsistent grammar. Consider:

    // the brace must go on the same line as the tag
    // unless a special (inconsistent) exception were made
    type Thing struct `tag:"thing"` {
    Field1 int `tag:"stuff"`
    }
    type Integer int `tag:"other thing"`

    In the above, the tag in the struct case goes after the struct keyword.
    For primitive types, it'd Go after the type definition. Really, the only
    consistent approach is to put the tag after the entire type definition, and
    that'd result in:

    type Thing struct {
    Field1 int `tag:"stuff"`
    } `tag:"thing"`

    That looks a bit like typedef's in C, and typedef'd structs are pretty
    ugly.
    On Wednesday, December 4, 2013 8:03:04 AM UTC-7, Matt Sherman wrote:

    Struct (field) tags have proven very useful, and I am curious whether
    there has been consideration of offering the same at the type level? Would
    be handy for the stuff I am doing on gen<https://github.com/clipperhouse/gen>
    .

    Not sure where it would go syntactically, but something along the lines
    of:

    type Thing struct `tag:"thing"`
    {
    Field1 int `tag:"stuff"`
    }

    type Another []string `tag:"foo"`

    A bit of metadata would go a long way. Could apply to any type def, not
    just structs. Was there a particular design decision to only support struct
    fields?
    --
    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 4, '13 at 3:03p
activeDec 9, '13 at 1:00a
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase