The dot imports are useful, and others feel the same https://github.com/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. 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. By using dot imports you can promote user types to standard types. 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. 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 <dan...@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 <rengels@ix.netcom >>>> .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. -- 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.
