-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Embed seems cleaner #1
Comments
Thanks for the feedback. I had multiple Gophers contact me in regards to the embedding decision. I based the original embedding off SignalR and inheritance that an OOP language like C# provides. I was advised that it wasn't very "idiomatic" to have a package require that you embed a type to make it functional. I myself haven't seen many that require this (I think a couple of web frameworks do, for implementing an MVC pattern/controllers). I am still open to suggestions with this though. The overwhelming feeling seems to be that embedding is a no-no at the moment though. I wonder how people would feel if I were to make it a decision for the consumer? Perhaps a By the way .. hello to a fellow Australian Gopher :) |
G'day right back atcha! I hear you. I too am a C# developer exploring Go like you, so maybe that's why it looks wrong to me. I keep hearing the "not idiomatic" phrase a lot in the Golang world, but most of the time without a justification of WHY. I started building a website using my own MVC-like project structure and immediately was told just use routers and templates, MVC is "not idiomatic Go". I did change my code but in hindsight, I wish I did it my way. I also spoke to Andrew Gerrand in one of the earlier Sydney Go meetups about the various Go "web frameworks" (also usually frowned upon by the Go "idiomatic" purists, as you'd know) and he said the bottom line is, use whatever you like... whatever you feel most comfortable with... it's your code. So I would say, stick to your (aussie) guns and go with what you think is best :) |
What is the resoning behind this change:
You no longer need to embed *relayr.Relay .. but you now need to have all of your relay methods accept a *relayr.Relay as their first argument.
An empty struct looks awkward and then passing *relayr.Relay as the first argument to every single relay method seems less clean and going backwards IMO. The set-and-forget embedded struct and leaner methods seem to be better design.
The text was updated successfully, but these errors were encountered: