Yes, I thought about it and I am quite sure that it would be very complex code detecting referenced but unused code.
I am just starting with learning how to break things apart properly. Go makes it easy to modularise but old bad habits to make monolithic stuff don't dissolve overnight, and in my case I am working with a bitcoin client codebase that is very monolithic... Once things are properly decomposed it makes composition a lot easier and bugs are easier to find and fix when things are more properly isolated. On Friday, June 28, 2019 at 9:40:12 PM UTC+2, Ian Lance Taylor wrote: > > On Fri, Jun 28, 2019 at 11:39 AM <luka...@gmail.com <javascript:>> wrote: > > > > I am pretty sure that every folder in a Go code repository creates one > binary object, maybe two with a test package alongside it. It just didn't > occur to me that it would not trace the execution path of the main, and > where each of the closures/function references in this case are stored in a > map[string]*functype. > > > > If there could be an optimisation that omits them that would be cool but > I wasn't really thinking about it that way when I posted about it but more > just that 1 package = 1 module = 1 object. I unfortunately never had as > much time as I wanted when I first found Oberon to have already learned > this. > > > > No, just more highlighting the correspondence between binaries and the > folder tree as it replaces a makefile. > > > > I could probably avoid splitting the packages if I used tags but they > are not so easy to deal with and I'd rather learn the lesson of > structuring. Plus when I started I had in mind all-in-one and not to be > able to split things. I previously ran into another gotcha you can get when > you start out to write a main package and then realise you want to be able > to integrate its types and methods into another package. I would just say > that maybe it would be a good thing to put at the beginning of a course or > tutorial to highlight this pervasive but invisible factor when building > software and how it creates a lot of work when you don't think in terms of > modules and get stuck in the monolithic mindset. > > > Sorry, I'm not really sure what you mean. > > That said, the linker does discard functions that are never > referenced. But it does not in general discard methods that are never > referenced, because that is very hard to detect. Code can use the > reflect package to get a reflect.Value of that type, and can then call > methods using reflect.Value.Method. So it's difficult in general to > know whether a method is used or not. > > Ian > -- 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/e3dfd84b-287a-4e81-8f9f-aff27d725c81%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
