Count me among those who love the language just the way it is and regard
the prospect Go 2.0 with dread and loathing born of the Python 3
experience.
That being said, there's one itty-bitty change I'd like to advocate: *Allow
methods on primitives*.
I think I understand why allowing new methods on external packages is a bad
idea because it introduces a form of the fragile superclass problem. But
surely there's nothing fragile about strings, ints and floats.
Being unable to define a method on a string is *not* a showstopper since
one can always do "type Foo string" or use type-assertions. It's just that
it's inelegant in the case of a function that takes a recursive struct as
an argument if the leaves of the tree are strings. For example
type HTMLTree struct {
tag string
attributes string
content * Content //
}
type Content interface {
Render()
}
// NOT ALLOWED
func (s string) Render() {
}
So I have to do something like
type SC string
func (s SC) Render() {
}
but that means instead of being able to write
Div("", P("id=1", "When in the course of ..."))
one must use the wrapper type on every content string.
Div("", P("id=1", SC("When in the course of ...")))
Not the end of the world, but uglier than it ought to be, IMO.
Is there a way to get around this or, failing that, an explanation of why
methods on primitives are verboten?
Thanks!
--
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/6daa53b9-c2e6-48e8-b022-c8339d3b8dbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
