Is it a good practice to complement internal Gideros classes?

Apollo14

Hi guys!
Is it a good practice to complement internal Gideros classes instead of using global functions?

For example like here:

function Sprite:ignoreTouchHandler(event) -- Simple handler to ignore touches on a sprite. This blocks touches -- from other objects below it. if self:hitTestPoint(event.touch.x, event.touch.y) then event:stopPropagation() end end   function Sprite:ignoreMouseHandler(event) -- Simple handler to ignore mouse events on a sprite. This blocks mouse events -- from other objects below it. if self:hitTestPoint(event.x, event.y) then event:stopPropagation() end end   function Sprite:ignoreTouches(event) -- Tell a sprite to ignore (and block) all mouse and touch events self:addEventListener(Event.MOUSE_DOWN, self.ignoreMouseHandler, self) self:addEventListener(Event.TOUCHES_BEGIN, self.ignoreTouchHandler, self) end

Or here:

function TextField:sayPhrase(newPhraseString) local function addSymbol() for i=1, #newPhraseString do self:setText(utf8.sub(newPhraseString,1,i)) Core.yield(0.02) end end   Core.asyncCall(addSymbol) end

Or it is better to create regular functions?

pie

I think it all depends on what do you plan to do. You can also keep the base class as it is and make a class that inherits stuff from that to have additional functions:

function Balloon = Core.class(TextField)
function Ballon:sayphrase ()...

Forgive me i am on mobile

antix

I think it's fine to compliment them how you are doing.

tetnic

Technically you are doing what is called "extension" or "category" on some languages as obj-c and swift where you add behaviors directly to an existing class without use the inheritance mechanism.

You have another way to obtain the same, that is to create a direct subclass (Sprite in this case) by which each classes in your app (MyGameSprite, or TouchBlockingSprite, or even TouchBlockingSprite inheriting from MyGameSprite) will inherit wanted behavior.

Each of them have strengths and weaknesses.

The first represents a shortcut in the way you avoid the creation of a new class. It can be also useful if you want to change something "not complex" to an existing code.

I would prefer the second solution because gives you a greater level of flexibility, and responsibilities separation. What in fact if you need (to implement your behavior) to do an "override" of some existing behaviors of the superclass?

What if you need multiple objects do different things? Your risk is to finish with huge superclasses that does everything.

Obviously the choice depends on the size of your project, if it is relatively small the risk to lose control over your internal architecture is low.

Despite my English level I hope this could be useful to you-