On Fri, Jun 7, 2019 at 12:40 PM Michael Ellis <michael.f.el...@gmail.com> wrote:
>
> 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?

If one library defines string.Render() for html, and another defines
another string.Render() for, say, a graphics library, which Render
will be called when I call "str".Render()?

>
> 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.

-- 
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/CAMV2Rqo6vMmEOxTzp%2BB2AJXc-ZUuSpNP-7p0AYMoRd86-hR2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to