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