Author Topic: REQUEST: Make all unity methods used by NGUI-Components virtual protected  (Read 4216 times)

helmesjo

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 116
    • View Profile
I might be missing some magic Unity-feature but...

One thing I've been having alot of problem with is adding custom behaviour to NGUI-Components without changing any NGUI-code. Many times I'm in desperate need to add additional behaviour to something (e.g. UIDraggablePanel), but inheriting from this class won't give access to either Awake, Start or LateUpdate without hiding the baseclass-methods, so I'm completely crippled. Sure I can manually make the methods virtual in UIDraggablePanel, but I don't want to do this even if my life depended on it since this will give me hell later when I update NGUI.

Until now I've pretty much used whatever's been available and sometimes even duplicated NGUI code to not break anything, but it shouldn't be this much hassle. I know it's a boring task for you to change all 87 or so UI-classes you have (find-and-replace might to the trick?), but I really believe it's necessary to allow some flexability. As I said, there is almost always workarounds, but since each workaround is different from the other, it ends up in some inconsistent spagetti-code. Also, making them virtual protected won't break ANYTHING! :D

Anyways, cheers! :)

ArenMook

  • Administrator
  • Hero Member
  • *****
  • Thank You
  • -Given: 337
  • -Receive: 1171
  • Posts: 22,128
  • Toronto, Canada
    • View Profile
Every virtual function adds overhead and slows down the app. Plus virtual protected means there is always going to be a hierarchy of calls... simply put this is one feature request that will never come to light.

helmesjo

  • Full Member
  • ***
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 116
    • View Profile
Sure, it adds some overhead, but I can't imagine it even being noticeable... I definitely believe that whatever "overhead" this adds is worth it.

Still, if a class isn't inherited then there is basically no overhead at all so your classes would pretty much perform the same. It's only for increased flexibility for the developer (win-win). There is just too many cases where your classes don't include everything one would want (nothing bad with that, understandably they can't include everything everyone desires), so to just swoop this problem under the rock is not a bulletproof solution in my opinion.