Potential bug in the reflection system about pongo2

[flosch]

You're welcome! Yes, a better documentation is on my TODO list (#36). I will definitely work on better docs. :-)

[flosch]

It should work (and it works in the tests at least, for example here: https://github.com/flosch/pongo2/blob/master/pongo2_template_test.go#L44 and https://github.com/flosch/pongo2/blob/master/template_tests/complex.tpl#L22). Can you please provide more code (how you're creating the object and how you pass it to the template etc.) or - even better - a working minimal example where this does not work for you so it's possible for me to reproduce it? Thanks!

Are you sure you're passing a pointer to a Flash object to your context?

[ahall]

The flash object is not a pointer, but I still expected it to be able to call the method and be implicitly converted.

[flosch]

Method with pointer receivers are only part of the method set of *T (not T). If you have a method with a pointer receiver the object must be of type *Flash in order to access this method.

See https://golang.org/ref/spec#Method_sets:

A type may have a method set associated with it. The method set of an interface type is its interface. The method set of any other type T consists of all methods declared with receiver type T. The method set of the corresponding pointer type *T is the set of all methods declared with receiver *T or T (that is, it also contains the method set of T). Further rules apply to structs containing anonymous fields, as described in the section on struct types. Any other type has an empty method set. In a method set, each method must have a unique non-blank method name.

[ahall]

I would have expected this not to work then:

package main

import (
    "fmt"
)

type Blah struct {
    Name string
}

func (this *Blah) Test() string {
    return this.Name
}

func main() {
    b := Blah{Name: "Something"}
    fmt.Printf("Al: %s\n", b.Test())
}

Here b is not a pointer, yet it can call the Test() function. I would have the same expectation with the code in this issue.

[flosch]

The reason for that is https://golang.org/ref/spec#Calls:

A method call x.m() is valid if the method set of (the type of) x contains m and the argument list can be assigned to the parameter list of m. If x is addressable and &x's method set contains m, x.m() is shorthand for (&x).m()

pongo2 uses the reflect package do get the method set and it follows the before-mentioned definition of a method set. So yes, it works in Go, but it does not work in pongo2 which follows the strict method set definition. Your solution is to pass a pointer to an object (which is usually a good idea anyway).

[ahall]

Good to know and thanks for the clarification :). Just thought some of pongo2 users may get into the same issue, so perhaps we could document this.