Quick Links: Download Gideros Studio | Gideros Documentation | Gideros Development Center | Gideros community chat
Is it a good practice to complement internal Gideros classes? - Gideros Forum

Is it a good practice to complement internal Gideros classes?

Apollo14Apollo14 Member
edited August 2019 in Code snippets
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
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
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)
Or here:
function TextField:sayPhrase(newPhraseString)
	local function addSymbol()
		for i=1, #newPhraseString do
Or it is better to create regular functions?

Likes: MoKaLux

> Newcomers roadmap: from where to start learning Gideros
"What one programmer can do in one month, two programmers can do in two months." - Fred Brooks
“The more you do coding stuff, the better you get at it.” - Aristotle (322 BC)
+1 -1 (+1 / -0 ) Share on Facebook


  • piepie Member
    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 :)

    Likes: oleg, MoKaLux, Apollo14

    +1 -1 (+3 / -0 ) Share on Facebook
  • I think it's fine to compliment them how you are doing.

    Likes: MoKaLux, Apollo14

    +1 -1 (+2 / -0 ) Share on Facebook
  • tetnictetnic Member
    edited August 2019 Accepted Answer
    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-

    Likes: Apollo14, antix

    +1 -1 (+2 / -0 ) Share on Facebook
Sign In or Register to comment.