Add more tag literal to Go

[mei-rune]

I write a web application, hope write controller like spring mvc, as follows:

type Helloword struct {
    Controller

    Ctrl struct{}   `baseUrl:"/helloword"`
}

func (h *Helloword) Index(name `param:"name,maxLength=250,minLength=6"`  string) Result {
     `url:"index" method:“GET”`
    
      log(name, time.Now())
      return h.Render(R{"name": name})
}


func init() {
   RegistrController(&Helloword{})
}

In order to achieve this goal，I hope add Field with name is Tag and type is StructTag to reflect.Method,
add method with name is InTag to reflect.Type.

   ctrl := reflect.TypeOf(&Helloword())
   method, _ := ctrl.MethodByName("Index")
   fmt.Println(method.Tag.Get("url"))   // should print "index"
   fmt.Println(method.Tag.Get("method"))   // should print "GET"

   fmt.Println(method.Func.InTag(0).Get("param")) // shold print "name,maxLength=250,minLength=6"

Now, only add tag to field of struct. Can add more tag literal.

1. add tag literal to func

func add(x, y int) int {
   `path:"/add";argument:"x" argument:"y"`
 
   xxxxxx
}

or

func add(x  `argument:"x"`, y  `argument:"y"`  int) int {
   `path:"/add"`
 
   xxxxxx
}

2. -----dd tag literal to struct ---- (delete)

  struct {
   `name:"position_table" unique:"x+y"`

    X int
    Y int
  }

[minux]

For a language change proposal, you need to be much more detailed than this. As written, you didn't propose any way to access the tags for functions and structs, which makes them almost useless. I remember seeing discussions on this, but I don't have a link handy. Please see prior discussions before invest energy into writing a more detailed proposal. For one, the struct tag could be simulated by having the tag on a zero-sized field with proper name instead. And actually it's more flexible than attaching the tag to struct itself, as you can have multiple such fields (to split a large tag into multiple smaller ones, for example).

[dsnet]

Aside from a proposal write-up, what would be the use case for this?

[minux]

Not to say I endorse this proposal, but I do have got a need for these features. I have made a jni package that implements the JVM side of JNI, that is, it makes Go programs able to use Java extensions. To do that, I need to have Go types "implement" their Java counterpart, as expected by the Java extension. I don't want to use Java types in Go methods that implement Java types (besides, sometimes a Java long represent a unsigned integer, so I want to use uint64 for the Go type), so argument tagging could help me specify the Java equivalent type of a Go method argument, and method tag could tell the jni package the Java method name. Then Struct tag could give the equivalent Java class name. As a concrete example, let's say I want to implement this JavaClass, and implement the func method: package org.example; class JavaClass { private int func(long x, Object v); }; with the proposed additions, I can write this: type javaClass struct { `jni:"org.example.JavaClass" // this is the Java type this Go type implements // ... } // because the method will be invoked using reflect, // it has be exported, which means it has to use a // different name than its Java counterpart. func (o *javaClass) Func `jni:"func"` // this function tag gives the java method name (i uint64 `jni:"long"`, obj interface{} `jni:"Object"`) // argument tags give the Java type uint32 `jni:"int"` { // and then return tag gives the Java return value type // ... } I'm not saying this looks nice, but it certainly avoid having to scatter the data around (I'm currently using the method I mentioned in my last comment): type javaClass struct { jni.ClassName `jni:"org.example.JavaClass"` jni.MethodName `jni:Func=func(JLjava/lang/Object;)I"` // ... }

[myitcv]

@minux I could only recall #15398 but there may be other related issues/proposals/go-nuts posts

What follows is not a reflection per se on the proposal but an example of how we're working around the lack of struct/function/method tags.

My use case for something like this is similar @minux... but is at go generate-time; so I can get away with "special comments" (I've made-up this term; special comments are single line comments with no space after the //) in the function/method/struct body:

func MyFunc() {
    //my:special:comment1
    //my:special:comment2

    // the rest of my function
}

func (s *S) method1() {
    //mapsTo=apple.Bite

    // the rest of my method
}

type S struct {
    //mapsTo=apple
}

We then have a simple check that ensures:

• "special comments" are not part of the Doc *CommentGroup associated documentation of files/functions/imports etc
• all "special comments" are in some way recognised (go generate is one case obviously)
• special comments in function/method/struct bodies must appear before anything else, including other comments

Not ideal, but means, like your field-based solution, we can move on without a language change.

[mei-rune]

@myitcv How get "special comments" while program is running?

[bradfitz]

Dup of declined proposal #15398. See discussion there.