On Jun 9, 2019, at 7:42 AM, Michael Ellis <michael.f.el...@gmail.com> wrote: > > On Sunday, June 9, 2019 at 9:56:43 AM UTC-4, Bakul Shah wrote: > > 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 ...")) > > > Perhaps I'm misunderstanding, but I don't see how to make that work for tags > that can take both text or other elements without resorting to making the > content arguments of type interface{}. That's doable and the performance > penalty is negligible but it discards the benefit of Go's compile time type > checks. > > For reference, I've pasted together the guts of my html rendering code, > defined a couple of tag functions and added a short main to illustrate what > I'm doing at https://play.golang.org/p/_qZ7Oyv2Foa > > Any suggestions for cleanly allowing passing strings appreciated.
Actually this is a good candidate for sum-types, something I have wanted in Go (and IMHO something that fits in well). So for example: type Tree struct { T, A string C []Content empty bool } type Content_ interface { Render(b *bytes.Buffer, nindent int) error } type Content = Content_ | string ... Div("", "Here's a link", A("href=someURL", "to some URL"), "and so on").Render(&b, 0) This gives you better compile time checking and the same convenience as using interface{}. Unfortunately.... -- 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/12A0928E-E732-44AC-B44C-F31B46C7A464%40bitblocks.com. For more options, visit https://groups.google.com/d/optout.