Skip to content
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

Open
nkev opened this issue Mar 19, 2015 · 2 comments
Open

Embed seems cleaner #1

nkev opened this issue Mar 19, 2015 · 2 comments

Comments

@nkev
Copy link

nkev commented Mar 19, 2015

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.

@simon-whitehead
Copy link
Owner

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 relayr.AllowEmbedding() method to enable embedding?

By the way .. hello to a fellow Australian Gopher :)

@nkev
Copy link
Author

nkev commented Mar 19, 2015

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 :)
I haven't looked at your code in detail, but I bet someone will eventually say "it's not idiomatic Go to generate Javascript on the fly, like SignalR" and they will also not give you an alternative "idiomatic" solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants