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.

Reply via email to