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.
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.
