On Jun 9, 2019, at 6:14 AM, Michael Ellis <michael.f.el...@gmail.com> wrote:
>
> I'm not disputing the wisdom of Go's design. As I said at the top of the
> initial post, I like Go the way it is and see no need for a Go 2.
>
> I was trying to find a clean solution to a specific use case: nestable
> functions that generate html. Since new methods on primitives are not
> allowed (for good reason as I now understand) I wanted to at least inquire
> about the possibility of loosening the restrictions on a very specific case:
> function args whose type is effectively a string (or other primitive). I get
> the point the about types being not the same in terms of Go's internal
> bookkeeping. However, in this particular narrow case I don't see a hazard to
> maintainability because the rule forbidding new methods on primitives
> excludes any possibility of confusion within the body of the function.
>
> To my mind, having to define a type equivalent to a primitive solely for the
> purpose of implementing an interface detracts from readability. But given
> that there's good reason for the requirement I think being able to pass the
> equivalent primitive as a function argument of that type seems like a
> potentially safe way to make the code more readable.
On the flip side, when someone does
fmt.Printf("%v", someString)
I know exactly what will be printed; it doesn't depend on the context.
You are almost always going to call a string's Render function
(as you defined it in your original post) from a parent HTMLTree
struct' Render(), almost never in isolation -- except perhaps some
tests. So one suggestion is to deal with string rendering issues
in the parent HTMLTree struct's Render(). Now you can still say
Div("", P("id=1", "When in the course of ..."))
But you can use, e.g. Printf("%v", html.tag) and something different
occur. Another option is to have functions like Div and P accept
normal strings in convert them to application specific strings in
the function body.
In other words, the builtin types and the standard Go library provide
*no-surprises* behavior but that may not be enough for any application
specific needs and it is better to just build what you need without
changing the behavior of standard components that everyone relies on.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/BEC2C543-76E5-4F0F-B97D-1FF052F62CD6%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.
