code review 5415060: text/template: new, simpler API

text/template: new, simpler API

The Set type is gone. Instead, templates are automatically associated by
being parsed together; nested definitions implicitly create associations.
Only associated templates can invoke one another.

This approach dramatically reduces the breadth of the construction API.

For now, html/template is deleted from src/pkg/Makefile, so this can
be checked in. Nothing in the tree depends on it. It will be updated next.

[r, 2011-11-21 05:01:55]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg/

[dsymonds, 2011-11-21 06:13:59]

I've only looked at the API in {doc,helper,template}.go. I like where it's
heading.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go
File src/pkg/text/template/doc.go (right):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:21: Once constructed, templates can be executed
safely in parallel.
probably clearer to phrase with a singular template to make it clear that each
template execution is concurrent-safe with itself, not just with other
templates.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:224: template, then in the global function map.  By
default, no functions are defined
two spaces after ".".

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:268: Each template is named by a string specified
when it is created. Also, each
worth mentioning that the template namespace is the set of templates that are
associated with each other?

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:306: multiple associated templates by reading
files.
"multiple" seems redundant here.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:308: A template may be executed directly or through
ExecuteTemplate, which executes an
wrap

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (left):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go#...
src/pkg/text/template/helper.go:30: func ParseFile(filename string) (*Template,
error) {
Can we keep this as a trivial wrapper around ParseFiles? It's a very common
case.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (right):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go#...
src/pkg/text/template/helper.go:61: // ParseGlob creates a new Template and
parses the template definition from the
"definitions"?

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/template.go
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/template.g...
src/pkg/text/template/template.go:50: func (t *Template) NewTemplate(name
string) *Template {
Could this just be called New? That would parallel ParseFiles as both function
and method.

[r, 2011-11-21 06:26:59]

Hello golang-dev@googlegroups.com, dsymonds@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[r, 2011-11-21 06:27:07]

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go
File src/pkg/text/template/doc.go (right):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:21: Once constructed, templates can be executed
safely in parallel.
On 2011/11/21 06:14:00, dsymonds wrote:
> probably clearer to phrase with a singular template to make it clear that each
> template execution is concurrent-safe with itself, not just with other
> templates.

Done.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:224: template, then in the global function map.  By
default, no functions are defined
On 2011/11/21 06:14:00, dsymonds wrote:
> two spaces after ".".

Done.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:268: Each template is named by a string specified
when it is created. Also, each
On 2011/11/21 06:14:00, dsymonds wrote:
> worth mentioning that the template namespace is the set of templates that are
> associated with each other?

i thought that was clear, but OK.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:306: multiple associated templates by reading
files.
On 2011/11/21 06:14:00, dsymonds wrote:
> "multiple" seems redundant here.

Done.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/doc.go#new...
src/pkg/text/template/doc.go:308: A template may be executed directly or through
ExecuteTemplate, which executes an
On 2011/11/21 06:14:00, dsymonds wrote:
> wrap

Done.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (left):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go#...
src/pkg/text/template/helper.go:30: func ParseFile(filename string) (*Template,
error) {
On 2011/11/21 06:14:00, dsymonds wrote:
> Can we keep this as a trivial wrapper around ParseFiles? It's a very common
> case.

why? just pass one file.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (right):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go#...
src/pkg/text/template/helper.go:61: // ParseGlob creates a new Template and
parses the template definition from the
On 2011/11/21 06:14:00, dsymonds wrote:
> "definitions"?

Done.

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/template.go
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/template.g...
src/pkg/text/template/template.go:50: func (t *Template) NewTemplate(name
string) *Template {
On 2011/11/21 06:14:00, dsymonds wrote:
> Could this just be called New? That would parallel ParseFiles as both function
> and method.

Done.

[dsymonds, 2011-11-21 06:31:48]

LGTM

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (left):

http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go#...
src/pkg/text/template/helper.go:30: func ParseFile(filename string) (*Template,
error) {
On 2011/11/21 06:27:07, r wrote:
> On 2011/11/21 06:14:00, dsymonds wrote:
> > Can we keep this as a trivial wrapper around ParseFiles? It's a very common
> > case.
> 
> why? just pass one file.

Just that
  template.ParseFile("foo.html")
is much easier to get right for n00bs than
  template.ParseFiles([]string{"foo.html"}...)

[adg, 2011-11-21 06:36:54]

On 21 November 2011 17:31,  <dsymonds@golang.org> wrote:
> LGTM
>
>
> http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go
> File src/pkg/text/template/helper.go (left):
>
>
http://codereview.appspot.com/5415060/diff/1/src/pkg/text/template/helper.go#...
> src/pkg/text/template/helper.go:30: func ParseFile(filename string)
> (*Template, error) {
> On 2011/11/21 06:27:07, r wrote:
>>
>> On 2011/11/21 06:14:00, dsymonds wrote:
>> > Can we keep this as a trivial wrapper around ParseFiles? It's a very
>
> common
>>
>> > case.
>
>> why? just pass one file.
>
> Just that
>  template.ParseFile("foo.html")
> is much easier to get right for n00bs than
>  template.ParseFiles([]string{"foo.html"}...)

It's just:
  ParseFiles("foo.html")

[dsymonds, 2011-11-21 06:38:22]

Oops.

[rsc, 2011-11-21 17:02:59]

LGTM

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/exec.go
File src/pkg/text/template/exec.go (right):

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/exec.go...
src/pkg/text/template/exec.go:88: // ExecuteTemplate applies the template
associated with t that has given name to
s/has/has the/

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/parse/p...
File src/pkg/text/template/parse/parse.go (right):

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/parse/p...
src/pkg/text/template/parse/parse.go:181: t.errorf("template: %q multiply
defined", t.Name)
multiple definitions of template %q

(no one will read 'multiply' as an adverb)

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/templat...
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/templat...
src/pkg/text/template/template.go:50: func (t *Template) New(name string)
*Template {
I am slightly worried about exposing this method, as it opens
the door to holding multiple *Template values that are different
entry points into the same set.  It might be better to have only
Parse as the entry point for creating subtemplates.

Are there cases that need this?

[r, 2011-11-21 17:43:37]

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/exec.go
File src/pkg/text/template/exec.go (right):

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/exec.go...
src/pkg/text/template/exec.go:88: // ExecuteTemplate applies the template
associated with t that has given name to
On 2011/11/21 17:03:00, rsc wrote:
> s/has/has the/

Done.

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/parse/p...
File src/pkg/text/template/parse/parse.go (right):

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/parse/p...
src/pkg/text/template/parse/parse.go:181: t.errorf("template: %q multiply
defined", t.Name)
On 2011/11/21 17:03:00, rsc wrote:
> multiple definitions of template %q
> 
> (no one will read 'multiply' as an adverb)

Done.

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/templat...
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/2002/src/pkg/text/template/templat...
src/pkg/text/template/template.go:50: func (t *Template) New(name string)
*Template {
it's used to implement ParseFiles, which all the helpers depend on, but at least
for now can unexport it.

but now i'll contradict myself.

i see no technical reason to forbid "multiple entry points". in fact, i can see
a  use, characterized by ParseFiles. since the templates form a name space,
multiple "entry points" as you call them can be distinct pages that share common
infrastructure. since ParseFiles lets you build such a thing one way, why not
let the user build them by hand?

i'll leave it exported unless you have a counterargument.

[r, 2011-11-21 17:44:17]

Hello dsymonds@golang.org, adg@golang.org, rsc@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[rsc, 2011-11-21 17:49:48]

On Mon, Nov 21, 2011 at 12:43,  <r@golang.org> wrote:
> i see no technical reason to forbid "multiple entry points". in fact, i
> can see a  use, characterized by ParseFiles. since the templates form a
> name space, multiple "entry points" as you call them can be distinct
> pages that share common infrastructure. since ParseFiles lets you build
> such a thing one way, why not let the user build them by hand?

The only reason is to give yourself flexibility in the future.
Right now the implementation uses *Template to denote both
the collection and individual elements of the collection.
It seems possible that in the future you might want to
have a separate type for the elements than for the set,
(say, *template for an element, *Template for the set),
and exposing this detail, which few people will use anyway,
restricts such a change.  It's fine either way.

Russ

[r2, 2011-11-21 17:54:40]

On Nov 21, 2011, at 9:49 AM, Russ Cox wrote:

> On Mon, Nov 21, 2011 at 12:43,  <r@golang.org> wrote:
>> i see no technical reason to forbid "multiple entry points". in fact, i
>> can see a  use, characterized by ParseFiles. since the templates form a
>> name space, multiple "entry points" as you call them can be distinct
>> pages that share common infrastructure. since ParseFiles lets you build
>> such a thing one way, why not let the user build them by hand?
> 
> The only reason is to give yourself flexibility in the future.
> Right now the implementation uses *Template to denote both
> the collection and individual elements of the collection.
> It seems possible that in the future you might want to
> have a separate type for the elements than for the set,
> (say, *template for an element, *Template for the set),
> and exposing this detail, which few people will use anyway,
> restricts such a change.  It's fine either way.

having just spent four days removing the difference in type between the elements
and the set, i feel unkeen to separate them again.  you're seeing the way this
works differently from me, i think. there is no "set", there's just a
relationship between *Templates and any one of them gives you access to the
others, either through template actions or ExecuteTemplate.

but you have a point about flexibility. i'll unexport it and see who screams.

-rob

[r, 2011-11-21 17:55:30]

Hello dsymonds@golang.org, adg@golang.org, rsc@golang.org, r@google.com (cc:
golang-dev@googlegroups.com),

Please take another look.

[r2, 2011-11-21 17:58:26]

(also, the Template and Templates methods let you get at other members of the
set, so controlling the construction doesn't add much)

-rob

[gri, 2011-11-21 18:09:22]

LGTM

http://codereview.appspot.com/5415060/diff/5016/src/pkg/text/template/exec.go
File src/pkg/text/template/exec.go (right):

http://codereview.appspot.com/5415060/diff/5016/src/pkg/text/template/exec.go...
src/pkg/text/template/exec.go:88: // ExecuteTemplate applies the template
associated with t that hasthe given name
s/hasthe/has the/

http://codereview.appspot.com/5415060/diff/5016/src/pkg/text/template/exec.go...
src/pkg/text/template/exec.go:89: // to the specified data object, writing the
output to wr.
s/writing/and writes/ ?

[r2, 2011-11-22 01:25:44]

On Nov 21, 2011, at 4:46 PM, Ugorji wrote:

> Just one thought.
> 
> Is there a way to share parse trees? 

No, but I understand the need. The issue is safety in the context of
html/template, but I think it should be very easy to clone a template, sharing
the parse trees but creating a separate name space and security box. I'll talk
to Mike about it - I need to talk to him anyway because I need to figure out how
to make html/template work with the new API.

-rob

[MikeSamuel, 2011-11-23 17:04:05]

On 2011/11/22 01:25:44, r2 wrote:
> On Nov 21, 2011, at 4:46 PM, Ugorji wrote:
> 
> > Just one thought.
> > 
> > Is there a way to share parse trees? 
> 
> No, but I understand the need. The issue is safety in the context of
> html/template, but I think it should be very easy to clone a template, sharing
> the parse trees but creating a separate name space and security box. I'll talk
> to Mike about it - I need to talk to him anyway because I need to figure out
how
> to make html/template work with the new API.
> 
> -rob

I did implement subtree cloning in
http://code.google.com/p/go/source/browse/src/pkg/html/template/clone.go and can
use that to defensively copy trees that require patching if you want
text/template to share trees.

[MikeSamuel, 2011-11-23 17:04:45]

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/exec_t...
File src/pkg/text/template/exec_test.go (right):

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/exec_t...
src/pkg/text/template/exec_test.go:672: err = tmpl.Template("tree").Execute(&b,
tree)
Maybe test that ExecuteTemplate(name, ...) is equivalent to
tmpl.Template(name).Execute(...)

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (right):

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/helper...
src/pkg/text/template/helper.go:45: // template is nil, it is created from the
first file.
Ok.  Even if some glob primitives don't return files in a predictable order,
since the templates are all related, you just need to use .Template(...) or
.ExecuteTemplate(...) to restore predictability.

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/parse/...
File src/pkg/text/template/parse/parse.go (right):

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/parse/...
src/pkg/text/template/parse/parse.go:181: t.errorf("template: multiple
definition of template %q", t.Name)
Maybe include the file from which t's body originated.
Did you mean to replace the existing definition or return here?

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/parse/...
src/pkg/text/template/parse/parse.go:195: newT := New("definition") // name will
be updated once we know it.
Ok.  As long as the name is updated before newT.init() happens there's no need
to later remove newT.common.tmpl["definition"].

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/templa...
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/templa...
src/pkg/text/template/template.go:111: // definitions) and would replace a
non-trivial template with the same name.
Why the "non-trivial" in "would replace a non-trivial template"?

associate below is doing something akin to replacing a prototype with an
implementation.  Is this fixing up templates that were created with one name
with implementations, or is this a feature that you intend users to exploit by
creating empty templates in one file and providing non-trivial implementation in
other files that may or may not be loaded?

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/templa...
src/pkg/text/template/template.go:120: // The receiver template should rewritten
not recreated.
should [be] rewritten

[r, 2011-11-23 17:18:19]

Hello dsymonds@golang.org, adg@golang.org, rsc@golang.org, r@google.com,
gri@golang.org, mikesamuel@gmail.com (cc: golang-dev@googlegroups.com),

Please take another look.

[r, 2011-11-23 17:19:18]

I rearranged some code and cleaned up the paths. I think this is ready.

Added fixes to all the affected code except html/template

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (right):

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/helper...
src/pkg/text/template/helper.go:45: // template is nil, it is created from the
first file.
On 2011/11/23 17:04:45, MikeSamuel wrote:
> Ok.  Even if some glob primitives don't return files in a predictable order,
> since the templates are all related, you just need to use .Template(...) or
> .ExecuteTemplate(...) to restore predictability.

path/filepath.Glob sorts, so it should be ok

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/parse/...
File src/pkg/text/template/parse/parse.go (right):

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/parse/...
src/pkg/text/template/parse/parse.go:181: t.errorf("template: multiple
definition of template %q", t.Name)
On 2011/11/23 17:04:45, MikeSamuel wrote:
> Maybe include the file from which t's body originated.
> Did you mean to replace the existing definition or return here?

t.errorf will not return; it "errors out"

it would be nice to have the file name but this code has no files, just strings.
we're a long way from home.

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/parse/...
src/pkg/text/template/parse/parse.go:195: newT := New("definition") // name will
be updated once we know it.
On 2011/11/23 17:04:45, MikeSamuel wrote:
> Ok.  As long as the name is updated before newT.init() happens there's no need
> to later remove newT.common.tmpl["definition"].

Done.

yes, that's true

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/templa...
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/templa...
src/pkg/text/template/template.go:111: // definitions) and would replace a
non-trivial template with the same name.
On 2011/11/23 17:04:45, MikeSamuel wrote:
> Why the "non-trivial" in "would replace a non-trivial template"?
> 
> associate below is doing something akin to replacing a prototype with an
> implementation.  Is this fixing up templates that were created with one name
> with implementations, or is this a feature that you intend users to exploit by
> creating empty templates in one file and providing non-trivial implementation
in
> other files that may or may not be loaded?

Done.

http://codereview.appspot.com/5415060/diff/15001/src/pkg/text/template/templa...
src/pkg/text/template/template.go:120: // The receiver template should rewritten
not recreated.
On 2011/11/23 17:04:45, MikeSamuel wrote:
> should [be] rewritten

Done.

[r, 2011-11-23 18:48:44]

Hello dsymonds@golang.org, adg@golang.org, rsc@golang.org, r@google.com,
gri@golang.org, mikesamuel@gmail.com (cc: golang-dev@googlegroups.com),

Please take another look.

[r2, 2011-11-23 18:49:42]

I added a Copy method as requested by Ugorji, since Mike thinks that case can be
handled.

-rob

[MikeSamuel, 2011-11-23 19:15:55]

LGTM

[nigeltao, 2011-11-23 22:43:13]

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/templa...
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/templa...
src/pkg/text/template/template.go:75: func (t *Template) Copy() *Template {
IIRC, we had this naming discussion for protobufs, and the consensus was that
this sort of operation, returning a new object, is called Clone. Copy means
duplicating into an existing target, such as the built-in copy or io.Copy.

[nigeltao, 2011-11-23 22:54:09]

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (right):

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/helper...
src/pkg/text/template/helper.go:37: // ParseFiles parses the named files and
associates the resulting templates with t.
80 chars for doc comments.

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/templa...
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/templa...
src/pkg/text/template/template.go:102: // Template returns a slice of the
templates associated with t, including t itself.
s/Template/Templates/, and watch the 80 char limit for doc comments.

[r, 2011-11-24 04:02:13]

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/helper.go
File src/pkg/text/template/helper.go (right):

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/helper...
src/pkg/text/template/helper.go:37: // ParseFiles parses the named files and
associates the resulting templates with t.
On 2011/11/23 22:54:09, nigeltao wrote:
> 80 chars for doc comments.

Done.

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/templa...
File src/pkg/text/template/template.go (right):

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/templa...
src/pkg/text/template/template.go:75: func (t *Template) Copy() *Template {
On 2011/11/23 22:43:13, nigeltao wrote:
> IIRC, we had this naming discussion for protobufs, and the consensus was that
> this sort of operation, returning a new object, is called Clone. Copy means
> duplicating into an existing target, such as the built-in copy or io.Copy.

Done.

http://codereview.appspot.com/5415060/diff/14005/src/pkg/text/template/templa...
src/pkg/text/template/template.go:102: // Template returns a slice of the
templates associated with t, including t itself.
On 2011/11/23 22:54:09, nigeltao wrote:
> s/Template/Templates/, and watch the 80 char limit for doc comments.

Done.

[r, 2011-11-24 04:04:15]

Hello dsymonds@golang.org, adg@golang.org, rsc@golang.org, r@google.com,
gri@golang.org, mikesamuel@gmail.com, nigeltao@golang.org (cc:
golang-dev@googlegroups.com),

Please take another look.

[r2, 2011-11-24 04:05:08]

New CL description:

	text/template: new, simpler API
	
	The Set type is gone. Instead, templates are automatically associated by
	being parsed together; nested definitions implicitly create associations.
	Only associated templates can invoke one another.
	
	This approach dramatically reduces the breadth of the construction API.

	For now, html/template is deleted from src/pkg/Makefile, so this can
	be checked in. Nothing in the tree depends on it. It will be updated next.

I plan to check this in today. Mike and/or I will work on html/template.

-rob

[adg, 2011-11-24 04:05:55]

LGTM

[r, 2011-11-24 04:17:26]

*** Submitted as http://code.google.com/p/go/source/detail?r=45e3c28dc7b5 ***

text/template: new, simpler API

The Set type is gone. Instead, templates are automatically associated by
being parsed together; nested definitions implicitly create associations.
Only associated templates can invoke one another.

This approach dramatically reduces the breadth of the construction API.

For now, html/template is deleted from src/pkg/Makefile, so this can
be checked in. Nothing in the tree depends on it. It will be updated next.

R=dsymonds, adg, rsc, r, gri, mikesamuel, nigeltao
CC=golang-dev
http://codereview.appspot.com/5415060