I don’t think that’s an issue. You only have references to both Employee in the integration code, and that should probably always use fully qualified names - if I’m understanding your concerns, but I’m not sure I am.
> On Dec 3, 2018, at 10:23 AM, 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.
