Author Topic: Trigger Naming Conflict  (Read 2102 times)

beck

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 6
    • View Profile
Trigger Naming Conflict
« on: February 17, 2014, 03:19:22 PM »
Hi, I've run into a problem when integrating NGUI into an existing project. In several places (AnimationOrTween.cs, UIButtonMessage.cs, perhaps others) you have declared a Type named Trigger. In all cases it seems that they are declared in a namespace or nested in a class. In my project I have a MonoBehaviour named Trigger which acts as a helper behaviour for polling the current state of a collider marked as isTrigger. Because your declarations are nested, I don't get a naming conflict error, but all your references to the Trigger classes are naked and end up targeting my Trigger class in the global namespace. I was able to solve my problem by renaming my Trigger class to TriggerBehaviour - not ideal, but it is a path of lesser resistance than altering the NGUI codebase.

My request is that since Trigger is a common name, could you add using statements to the top of scripts which reference the Trigger types to clear up namespace conflicts? For example, in UIButtonMessage you would add "using Trigger = UIButtonMessage.Trigger;".

I understand if this is not a solution you'd like to pursue, but I wanted to throw out my recommendation in case you are willing to accomodate.

Thanks,
- Beck

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Re: Trigger Naming Conflict
« Reply #1 on: February 18, 2014, 07:59:41 AM »
NGUI's trigger is in a namespace, yours isn't -- which is where the trouble comes from. I can't simply change its name without breaking backwards compatibility and I can't do "using Trigger = AnimationOrTween.Trigger;" because I'd need to do it in a lot of places, and it would only cover one user case -- Trigger. Then the next person will come along and complain about "Direction" from the same namespace.

Bottom line is you shouldn't have such a commonly named class in a global namespace. Separate it by putting it into its own namespace, or make it a part of some other class.