>
> 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()?
Method call syntax is the least of the worries. Presumably, that could be
based on which packages are imported in the calling context, and you'd get
an error if it's ambiguous. The larger problem is when you get interfaces
involved. Two Content variables storing the same value of type string could
have different implementations of Render depending on where the interface
value was created. And if a variable v of type Content is used in a way
equivalent to interface{}(v).(Content), you could end up changing the
implementation of Render or failing the assertion altogether. So, the
problem with allowing an arbitrary package to define methods on primitive
types isn't with method call syntax, it's with using such methods to
satisfy an interface like Content.
One workaround would be to allow you to use package-qualified method names,
so
package foo
type Content interface {
package.Render()
}
func (s string) package.Render() { ... }
At minimum, package-qualified methods defined in other packages couldn't be
used to satisfy Content. Normal Render methods defined in other packages
(for types which have to be defined in those packages) could be allowed to
satisfy the interface, and/or other packages could be allowed to define
methods like
func (t T) foo.Render() { ... }
for their own types to satisfy the interface.
There hasn't been much interest in pursuing anything like this for Go,
however. Something like the sum types mentioned by Bakul might be a better
match for existing Go idioms, since it could be a swap-in replacement for
interface{} in existing functions that use a type switch with an interface
fallback, allowing them to better specify which types they support. Of
course, there's also been opposition to adding sum types, since many see
interfaces as "good enough" to cover the use cases of sum types.
On Fri, Jun 7, 2019 at 3:00 PM Burak Serdar <bser...@ieee.org> wrote:
> 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.
>
--
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/CANjmGJsfSYVtefWN7jxv7J1v607HWuMq6q5_KaZat0yfpbH%3DtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
