Identifiers defined in the main
package cannot be referred to from other packages, so an exported identifier from a plugin cannot be the same type what you have in your main app. Even if you would duplicate the Person
type both in the plugin's file and in your main app, type assertion would fail because they are not the same type!
But it is possible to define the type in a separate package, and use this same package in the plugin and in the main app. And then you can type assert this type from a symbol you lookup from the plugin.
See this example:
The separate type defined in its own package:
package filter
type Filter struct {
Name string
Age int
}
Plugin code:
package main
import (
"play/filter"
)
var MyFilter = filter.Filter{
Name: "Bob",
Age: 21,
}
func CreateFilter() filter.Filter {
return filter.Filter{
Name: "Bob",
Age: 21,
}
}
The main app:
package main
import (
"fmt"
"log"
"os"
"play/filter"
"plugin"
)
func main() {
p, err := plugin.Open("plugin.so")
if err != nil {
log.Fatal(err)
}
mf, err := p.Lookup("MyFilter")
if err != nil {
log.Fatal(err)
}
f, ok := mf.(*filter.Filter)
if !ok {
log.Fatal("Wrong symbol type")
}
fmt.Printf("%+v
", f)
}
Running the main app, the output is:
&{Name:Bob Age:21}
What you may notice is that the exported identifier in the plugin MyFilter
is a variable of non-pointer type, yet we type-asserted a pointer type from the exported symbol. This is because if you lookup a variable, you will get a pointer to it, else you could not modify the value of the variable, you could only modify the copy. This is detailed in this answer: Plugin symbol as function return
This is not the case if we lookup the other symbol our plugin exports: the CreateFilter()
function which returns a value of non-pointer type filter.Filter
:
cf, err := p.Lookup("CreateFilter")
if err != nil {
log.Fatal(err)
}
createFilter, ok := cf.(func() filter.Filter)
if !ok {
log.Fatal("Wrong function type")
}
f2 := createFilter()
fmt.Printf("%+v
", f2)
Running this code, the output will be:
{Name:Bob Age:21}
See related question: go 1.8 plugin use custom interface
Also note that if you change the filter
package used commonly by the plugin and the main app, you also have to rebuild the plugin. Attempting to run the app without rebuilding the plugin will result in an error during the plugin.Open()
call. For details, see How do Go plugin dependencies work?