Hey Paul, I think those are interesting ideas, but my concern about scope-local methods extends beyond just the methods of the sort.Interface interface; I was just using that as an example. The same complaint applies for any type used only within a given scope that needs to implement any interface.
Cheers, Josh On Friday, August 19, 2016 at 3:28:33 AM UTC-7, Paul Jolly wrote: > > I've been following the same Github issue. > > >> ... but the particularly annoying part is having to clutter the global >> namespace by adding a global type which implements the interface >> > > As part of an extension to sortGen > <https://github.com/myitcv/sorter/tree/master/cmd/sortGen> I've also been > thinking about this question, for both types and functions. > > But I've been trying to answer it in the context of ensuring that > compile-time > optimisation is still possible > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgolang%2Fgo%2Fissues%2F16721%23issuecomment-240970016&sa=D&sntz=1&usg=AFQjCNEQ1Xulxn9t6rJnSBF-gTNq9CMKrg> > . > > My current thinking is that I will create an internal package > <https://docs.google.com/document/d/1e8kOo3r51b2BWtTs_1uADIA5djfXhPT36s6eHVRIvaU/edit> > (as > part of my code generation) to contain the function/type. > > I think this approach will also work in your situation. Thoughts? > -- 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. For more options, visit https://groups.google.com/d/optout.
