Anyway, thanks all for the input. I am continuing to review other large code based for real world examples for what works and what doesn’t and having the input of the community makes understanding the conventions easier.
> On Dec 3, 2018, at 10: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. > > 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.
