On Thu, 2018-11-29 at 17:07 -0600, robert engels wrote: > The dot imports are useful, and others feel the same https://github.c > om/golang/lint/issues/179 > <https://github.com/golang/lint/issues/179>. When you make statements > like, > > > > > Now given that dot imports are generally considered a bad idea in > > Go > It feels a lot like the “cut off the sides of the roast to fit it in > the oven”. > > As I cited, there were static imports added to Java a long time ago, > and it is not a problem. Clearly it can’t be that challenging to Go > developers.
Just because something existed somewhere else with different context (where is may or may not have been a good idea) means that it will be a good idea here. > In Java you don’t write java.lang.Object… you write Object. Similarly > in Go, I don’t write github.com/golang/go/runtime/X > <http://github.com/golang/go/runtime/X> I write runtime.X and I don’t > write go.int64 I write int64 - why? because int64 is a language > specified type. There's a significant difference here. In go we don't continually reiterate the import path is is unfortunately the case in java. That additional verbosity is possibly a reason why it might have been a good idea in java, though eliding the redundant path information at the call site probably would have been better. > By using dot imports you can promote user types to standard types. And in my experience this leads to additional cognitive load on the maintainer. A similar argument exists for why operator overloading doesn't exist in Go. > When writing application code - not systems code - you are often > working in a constrained environment that the architect has chosen. > The dot imports allow the coding to be close to a DSL. Maybe I create > a package ‘common’ that has “wrappers/facades’ for a lot of > APIs/packages I want my developers to use, but I don’t want to expose > all of the functionality. By using a dot import on the common > package, the developer works with a concept “Fixed” - she doesn’t > need to know it is maybe a decimal.Decimal behind the scenes, and it > has a API limited to the solving the problem domain. The labels make close to zero difference here. If the user wants to make a dsl, they can do that, but don't expect me to consume their code. > It allows the designer and extra layer of abstraction and > simplification. The developers don’t need to import/learn a gazillion > packages with hundreds of methods, they import ‘common’ as a facade > providing a simplified interface to the system. Having to prefix > every type with ‘common' is senseless. In reality there would > probably be multiple packages, like ‘common’, ‘printing’, ‘security’, > ‘database' etc. but even then the name collision would be limited by > the designer. This is enterprise/framework design 101. > > > > > > > > > On Nov 29, 2018, at 4:34 PM, Daniel Kortschak <dan...@kortschak.io> > > wrote: > > > > fixed.Number reduces stutter and is more informative. This was > > Jan's > > point. > > > > In general dot imports are a bad idea when maintaining large code > > bases > > since it requires more work to figure out what is actually > > providing > > the X that has been added to the . imports pool. It also a prevents > > the > > protection you get from importing colliding labels under different > > name > > spaces. foo.X and bar.X; import ( . "foo"; . "bar" ) and you have > > problems. > > > > When you change the rules of the game, of course you can win. My > > point > > below says that information is not reduced by lossless compression > > (your claim being the opposite). Given that as you show fixed.Fixed > > is > > almost completely compressible without any tricks to 50% its > > original > > size (almost because of the capitalisation, but given the > > requirement > > for exported labels to be capitalised we can invoke context, > > though... > > if you rename your package to Fixed, then you get perfect 50% > > compression without context). Now given that dot imports are > > generally > > considered a bad idea in Go and that as you show your label can be > > compressed, the conclusion is not that you should compress, but > > rather > > there is room to add additional information; fixed.Number. > > > > Thanks for playing! > > > > On Thu, 2018-11-29 at 16:24 -0600, robert engels wrote: > > > > > > Right and since fixed.Fixed can be reduced to Fixed with no loss > > > of > > > information, it is a great lossless compression - more than 50 %. > > > > > > Thanks for playing ! > > > > > > > > > > > > > > > > > > On Nov 29, 2018, at 4:11 PM, Daniel Kortschak <daniel@kortschak > > > > .io> > > > > wrote: > > > > > > > > That is correct. The number of physical bits used to represent > > > > the > > > > information is reduced. The number of bits of information > > > > remains > > > > the > > > > same except in the case of lossy compression. > > > > > > > > If this were not true, I could propose the following > > > > compression > > > > protocol: count the number of 1 bits in the uncompressed stream > > > > and > > > > represent this as a binary number, recursively apply this to > > > > the > > > > ones- > > > > count until you have one one bit. This is your compressed data. > > > > I > > > > have > > > > a truly marvellous decompression scheme to complement this, > > > > which > > > > this > > > > email is too narrow to contain (damn 80 column limit), but here > > > > is > > > > the > > > > compressed version, 0x1. > > > > > > > > On Thu, 2018-11-29 at 22:07 +0100, Jan Mercl wrote: > > > > > > > > > > > > > > > On Thu, Nov 29, 2018 at 10:02 PM robert engels <reng...@ix.ne > > > > > tcom > > > > > .com > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I’m pretty sure that is not correct, see > > > > > https://www.maximumcompression.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Most lossless text compression is > 85 %, and if you use > > > > > > lossy > > > > > compression (images, audio) it can be 100:1 > > > > > > > > > > Dan was talking about quite different bits. -- 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.
