if you anonymously embed a structure, the containing structure gets its methods. If the contained structure satisfies an interface, then the containing structure does as well.

Attempting to create inheritance features is ignoring the nature of Go's type system; it's the opposite of idiomatic.

Are you suggesting that the design would be better if instead Controller was an interface?

I agree that it seems enticing, for exactly the reason you mention. However, I think the interface solution would require setters and getters for every single field, which seems much worse to me.

>I think the interface solution would require setters and getters for every single field

not if you use struct tags. e.g.,

    type MyController struct {
        Id int `revel.q="id,required=true,min=0,max=200"`
    }

or something like that. Then the framework just fills the controllers field on an incoming request, based on what it finds in the struct tags. Then you have an interface that allows you to override that behavior, similar to how the json package will use the methods defined in `json.Unmarshaler` if you define them, but will fall back to controlling things by itself with reflection if you don't.