It would probably be useful, but to be fair, I rarely had this problem aside from sort. I think this mechanism is better suited for the occasional edge-case (as it doesn't require a language change): https://github.com/golang/go/issues/4146
On Fri, Aug 19, 2016 at 8:49 PM, Joshua Liebow-Feeser <he...@joshlf.com> wrote: > Does it really make sense to create an internal package just to define a > single small, one-off type? Also, I don't imagine that any of the > optimizations would need to be reconsidered; the scope is strictly a subset > of the scope at which the optimizations operated before, so there shouldn't > be any *new* optimizations that need to be made here. > > On Fri, Aug 19, 2016 at 11:46 AM, Paul Jolly <p...@myitcv.org.uk> wrote: > >> I did indeed mean to reply to all (done that this time)! >> >> Sure, I understand that it's "cleaner", but I'm advocating the internal >> package approach because: >> >> - it solves the problem today >> - it benefits from being able to take advantage of existing compile >> time optimisations without needing those same optimisations to be >> reconsidered in a world where such method sets can be defined within a >> scope other than the package scope >> >> But if you raised this point here in order to propose a language change, >> I'll quietly slip into the shadows! >> >> >> Paul >> >> >> On 19 August 2016 at 19:38, Joshua Liebow-Feeser <he...@joshlf.com> >> wrote: >> >>> Hi Paul, >>> >>> I think you meant to reply-all to the mailing list as well; this was >>> just sent to me :) >>> >>> My point is not about whether a type is exporter or not, but whether you >>> can define it inside a function or not. Consider the following two >>> implementations. This one <https://play.golang.org/p/fVfcSZPspO> is >>> valid Go today, but involves declaring the 'sortableInts' type at the >>> top-level, which in a complex file with a lot of code, can clutter things >>> up a lot. This one <https://play.golang.org/p/mvHJOj9htp> is not valid >>> Go, but is much cleaner - everything is contained within the function. >>> >>> Cheers, >>> Josh >>> >>> On Fri, Aug 19, 2016 at 11:31 AM, Paul Jolly <p...@myitcv.org.uk> wrote: >>> >>>> Hi Josh, >>>> >>>> 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. >>>>> >>>> >>>> But internal packages cover this case too, no? Apologies if I'm missing >>>> a more fundamental point you're making. >>>> >>>> Considering the case of go/ast.Visitor >>>> >>>> https://godoc.org/go/ast#Visitor >>>> >>>> An unexported type implementing this interface could be kept within an >>>> internal package, e.g. mydomain.com/banana/internal/typefinder, and an >>>> exported function used to access this behaviour >>>> >>>> // mydomain.com/banana/internal/typefinder.go >>>> package typefinder >>>> >>>> import ( >>>> "go/ast" >>>> ) >>>> >>>> type impl struct { >>>> nameToMatch string >>>> idents []*ast.Ident >>>> } >>>> >>>> func (i *impl) Visit(node ast.Node) ast.Visitor { >>>> switch node := node.(type) { >>>> case *ast.Ident: >>>> if node.Name == i.nameToMatch { >>>> i.idents = append(i.idents, node) >>>> } >>>> } >>>> return i >>>> } >>>> >>>> func GetMatches(name string, node ast.Node) []*ast.Ident { >>>> walker := &impl{ >>>> nameToMatch: name, >>>> } >>>> >>>> ast.Walk(walker, node) >>>> >>>> return walker.idents >>>> } >>>> >>>> >>>> And used from mydomain.com/banana as follows: >>>> >>>> >>>> // mydomain.com/banana.go >>>> package banana >>>> >>>> import ( >>>> "mydomain.com/banana/internal/typefinder" >>>> "go/ast" >>>> ) >>>> >>>> func myFunc() { >>>> var file *ast.File >>>> >>>> matches := typefinder.GetMatches("example", file) >>>> >>>> } >>>> >>>> The "issue" with this pattern is that you quickly arrive in a position >>>> where you have an internal package per helper type... maybe that's not a >>>> problem in and of itself however. >>>> >>>> Again, apologies if I missed your point. >>>> >>> >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/golang-nuts/ON-NFyhy23A/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts+unsubscr...@googlegroups.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. > 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. For more options, visit https://groups.google.com/d/optout.
