*type Content = Content_ | string*
That's a nice notation (and semantic). It certainly makes sense for this
case. Count me as a vote in favor.
*“I want you to act as if the house was on fire. Because it is.” — Greta
Thunberg*
On Sun, Jun 9, 2019 at 1:37 PM Bakul Shah <ba...@bitblocks.com> wrote:
> 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/CAK6kDbb742rksFkTJ7Y2aeG%2B4G0XT-qujhC8V_Y7c8qWjGcbew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
