I need to do a thorough summary, but as an example of things that could usefully change (perhaps) for improved coherence and excellence in Go2 through naming and simple rewrites, consider the image package.
1. The name of the package (fine always it seem, but in some cases maybe a change would help) 2. The name of functions and methods (fine generally, but a few oddities exist here and there) 3. The approach to special/exceptional actions. Image has a glaring issue here, described below. The way options/defaults/configurations are set varies between JPEG, PNG, and TIFF such that in one case you set an option via a method call, one via a "constructor" like list, one via a configuration struct that you pass in, and one voa a config struct that you call methods against. Any of these is fine to me, but having a variety of them is testament to the addition of image format support at different times by different hands and it would seem sad if Go17 was still this way. Instead, now that examples exist for each style, why not pick one of them (any one!) and convert the others to the same scheme. I know itr would be arbitrary breakage now, but that's paying forward for technical debt. When 1M Go developers becomes 10M, we'll have at 9M happy campers who never realized it was "wild" (disharmonious, unmutual) in the old days. 4. The approach to error labeling and categorization. 5. The "meta-ness" of the API. Hard to find the right way to say this, but for example, the filesystem APIs presume you're using the system native filesystem--naturally. But if you need to do all the same work but in a ZIP file, or in a custom binary blob with a file system inside, that ends up being a parallel construct rather than being able to say os.Open is the null case of MyFileSystem.Open with everything else in the filesystem API there naturally, or settabble in some way. Not arguing for any of these points here, just sharing that name polishing, unjustified variety in same-notion aspects of the API, and "only now do we realize that" generalizations all seem perfect subjects for careful review as part of the Go2 process. I'm in favor of the thought you're raising. Also, on the name front, it is not only the "package.Function()" that developers see, but hopefully more often it is variable.Method() and in case any package-name-based stuttering is gone. This is a subtle motivation to look for designs/refactorings that are heavy on methods on package types. (well...I think it is. there may not be consensus on that) Michael On Sat, Dec 1, 2018 at 6:52 AM Robert Engels <reng...@ix.netcom.com> wrote: > I disagree with a few of those, but the simplest example is image. There > still needs to be an image.Image interface for methods common to all image > types. Then sub packages for raster and vector (others?) There are too > many different image types so you end up a multitude of packages and since > package names need to be short you lose a lot of information. An easy > example is fractal. There are fractal images do you would have > fractal.Image but most people seeing a package called fractal would assume > it handle fractals.... > > Personally I would like to look at the documentation for the image package > to quickly see all of the supported types. > > Thus is why having a “rule” is tough to do in practice. > > > > On Dec 1, 2018, at 8:22 AM, Michael Jones <michael.jo...@gmail.com> wrote: > > I'll also add that personally I saw a lot of "change this" commentary with > rather little "thank you." That was not in the best spirit of what (at at > least I think) it should be. It's always good to act on ideas, build > solutions, and share results. It would be great if everyone always started > with that. You deserve it as does your code. > > Thank you! > Michael > > On Sat, Dec 1, 2018 at 6:17 AM Michael Jones <michael.jo...@gmail.com> > wrote: > >> I can see why you're feeling that. My sense is that what causes flare-ups >> is when people (universally rather than just here) get the feeling that the >> discussion is becoming personal rather than technical. Go is lots of >> people's work / tool / job / fun / etc., so passions may be strong, but >> I've never seen any tendency to be angry and protective about people >> raising issues with poor choices. What does come up is the desire for >> examples, use-cases, and other kinds of supporting information so that the >> conversation moves from "i feel that" ==> "in these situations" ==> "a >> workable resolution" ==> ... ==> "X seems the best way forward after much >> analysis." That made go great so far, and the conversations generally >> collegial. >> >> On Sat, Dec 1, 2018 at 6:00 AM Robert Engels <reng...@ix.netcom.com> >> wrote: >> >>> This is a problem with it seems more than a few in this community. >>> Someone makes a criticism of an idea, backs it up, and is treated in a >>> childish manner because it doesn’t go along with dominate opinions of the >>> controllers of the group think. Not good IMO. >>> >>> On Dec 1, 2018, at 7:48 AM, Jan Mercl <0xj...@gmail.com> wrote: >>> >>> On Sat, Dec 1, 2018 at 9:47 AM Dan Kortschak <d...@kortschak.io> wrote: >>> >>> > Very nice. >>> >>> Indeed >>> <https://drive.google.com/uc?id=1jQb9ISX5iavXkkaljPPhKpOItxvlEElt>. >>> >>> -- >>> >>> -j >>> >>> -- >>> 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. >>> >> >> >> -- >> >> *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* >> > > > -- > > *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* > > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
