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