4 ms·
>A Controller is any type that embeds revel.Controller (directly or indirectly). revel.Controller must be embedded as the first type in your struct (-‸ლ)
by zemo 13y ago
>A Controller is any type that embeds revel.Controller (directly or indirectly). revel.Controller must be embedded as the first type in your struct
(-‸ლ)
- coldtea 13y agoYou'd rather implement the interface methods yourself? Or you think it's possible to have some random type serve as a controller without the necessary interface by magic?
- zemo 13y agoif 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.
- robfig 13y agoAre 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.
- zemo 13y ago>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.