Originally Posted by Phanx
You're making this sound like way more work than it actually is:
|
Maybe I am, maybe it's a personal preference. To provide modularity here while using the original Frame methods (SetParent in this particular case), one would have to either pollute the Frame metamethods or add information about the created ui element's children to the parent frame (to be able to access them from somewhere else in case it's needed. local bags = New('Bags'); Bags.update()/Bags:update() for example). I personally chose composition (those tables people have so many problems with :O) so I wouldn't have to touch the host objects/classes/tables (prototypejs did this with their implementation for example and the rest is history).
Originally Posted by Phanx
Nothing needs to be moved around, re-indented, or wrapped in a new scope, and it's still straighforward, readable, and efficient code that isn't generating a bunch of extra tables or functions.
|
Again, sorry if I insulted anyone, but I think this thread is derailing a little
I could have my compiler (transpiler for nonbelivers!) generate exactly the code that you write here, I chose not to because I personally don't think it's modular, reusable or easily maintained.
Again, I really couldn't care if the finally generated lua code isn't readable and I do actually mimify the final code for production. I do care if it's slow/uses considerably more memory than other addons that provide the same functionality (which it doesn't so far).
p.s. I really think you have to change all the SetParent calls (or creation of textures/fontstrings) if you decide to put these buttons and text and textures in a new frame, no? Is there something I am missing here?