Whilst not exaclty the peek of modern tooling, grep is one method of checking where and how your package is used. That's a lot clearer without dot imports. I've never used a dot import, and don't think I have seen one in the wild. Allowing dot imports feels like a bit of a wart (but one that is easily, and widely, avoided). FWIW, I definitely did not feel that was on day 1 of my Go journey. All those package names looked annoying. I can't say when it stopped being annoying, but it didn't take long at all.
On Mon, 3 Dec 2018 at 16:23 Bakul Shah <ba...@bitblocks.com> wrote: > > > > On Dec 3, 2018, at 8:08 AM, Robert Engels <reng...@ix.netcom.com> wrote: > > > > I understand that, and when working in code that uses both types, which > is probably limited, you fully qualify. This is pretty standard stuff in > the enterprise world, as well architected solutions are segmented, so you > only encounter this problem at the integration points, and that code is > qualified. > > If you import another package where you are already using a dot import, > you are already using Employee. You then decide to change the new import > to dot import, at which point you discover the name clash. Now you have > to qualify all existing Employee references with the first package. So > a new import forces you to edit code that may have nothing to do with the > new import. > > If you don't do this, you will have Employee references (to the first pkg) > that are not qualified and some qualified ones. This will confuse things > because someone (or you, a few months later) will then go looking for > the Employee defn in your own package and not find it. > > It can all be made to work but why complicate things when a simple rule > suffices? > > > > > You have a similar problem if both applications have a model package. > Now you need to override the import on one of them. No difference IMO. > > > >> On Dec 3, 2018, at 10:03 AM, Bakul Shah <ba...@bitblocks.com> wrote: > >> > >>> On Dec 3, 2018, at 6:52 AM, Robert Engels <reng...@ix.netcom.com> > wrote: > >>> > >>> I think people are misunderstanding my equal footing need. I don’t > mean for all applications, I mean for a application. > >>> > >>> Here’s another example. You have a enterprise payroll application. You > have a model package. You have model.Employee. Having to use model.Employee > throughout the application is noise. Everyone working on the application > knows that Employee means model.Employee. It is part of the language (dsl > in a way) for that application. > >> > >> Now suppose you have to write a application that > >> has to access payroll as well as employee performance > >> review, health insurance, expense reporting, connect > >> to 3rd parties for special discounts for various things, > >> etc. Each of these subsystems may have their own > >> definition of Employee (which may be stored in their > >> own databases). This list may grow over time and you > >> don't want to have to recompile and retest *existing* > >> packages by changing some central Employee type. > > > > -- > 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.
