Jump to content




Object dependence in case of a GUI framework

lua

13 replies to this topic

Poll: Widget dependence

Which syntax do you prefer (please post a reason)

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.
Vote Guests cannot vote

#1 Sewbacca

  • Members
  • 450 posts
  • LocationStar Wars

Posted 24 May 2018 - 05:43 PM

Imagine you have a class called Widget. Now you create a object from Widget, and you would append it to the global Widget.

local wid = Widget()
wid:resize(10, 10)
-- #  wid:getSize() would return the witdth and the height of wid
-- #  imagine globalWidget would be the screen
globalWidget:addChild(wid)

Now, you want to reposition the widget. What do you think is better and/or more intuitive? Please give a reason (e. g. just more intuitive or an real advantage).
globalWidget:repositionChild(wid, 5, 5)
-- #  Or
wid:reposition(5, 5)

I am not sure, because the position of an object is an information that doesn't belongs to that (it doesn't defines the state of this object).

Edited by Sewbacca, 24 May 2018 - 06:40 PM.


#2 Windows10User

  • Members
  • 62 posts
  • LocationC:\Minecraft\saves\stuff\computer

Posted 24 May 2018 - 05:55 PM

I think wid:reposition is better.

#3 Sewbacca

  • Members
  • 450 posts
  • LocationStar Wars

Posted 24 May 2018 - 06:08 PM

View PostWindows10User, on 24 May 2018 - 05:55 PM, said:

I think wid:reposition is better.
Okay, but can you tell me please why? Is it just more intuitive or has it an advantage?

#4 EveryOS

  • Members
  • 570 posts
  • LocationOver there ->

Posted 24 May 2018 - 06:14 PM

It has reliance on less variables
Plus, it is better off to leave an object to modify it's own internals, in case they are changed

Edited by EveryOS, 24 May 2018 - 06:14 PM.


#5 Sewbacca

  • Members
  • 450 posts
  • LocationStar Wars

Posted 24 May 2018 - 06:26 PM

View PostEveryOS, on 24 May 2018 - 06:14 PM, said:

It has reliance on less variables
Plus, it is better off to leave an object to modify it's own internals, in case they are changed

It is a matter of perspective, because the parent object will hold the information for all pixels, to form the image. Or do you have another solution?

#6 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 24 May 2018 - 10:16 PM

I'd tell the child to move. Otherwise, what happens if you have children of children? You'd have to figure out parents of parents.

#7 KingofGamesYami

  • Members
  • 3,002 posts
  • LocationUnited States of America

Posted 24 May 2018 - 10:59 PM

In my experience with existing frameworks (eg. Qt), each "layer" of objects will have its own reposition-like method. That method shifts itself and all of its children.

#8 Sewbacca

  • Members
  • 450 posts
  • LocationStar Wars

Posted 25 May 2018 - 06:48 AM

View PostBomb Bloke, on 24 May 2018 - 10:16 PM, said:

I'd tell the child to move. Otherwise, what happens if you have children of children? You'd have to figure out parents of parents.

Think this is a good reason, i didn't thought in that way. Thank you!

#9 EveryOS

  • Members
  • 570 posts
  • LocationOver there ->

Posted 25 May 2018 - 11:24 AM

Also, what if you change the parent of the child? Sometimes it is possible to do so.

#10 Exerro

  • Members
  • 801 posts

Posted 25 May 2018 - 02:52 PM

I'd actually make it configurable. Giving parents control over child positioning lets you do cool things like auto-arranging grids/lists, and HTML-like 'flow' layouts. Of course, sometimes you want to just say "put this here exactly" so that's why I'd not say either one is the best standalone solution.

#11 EveryOS

  • Members
  • 570 posts
  • LocationOver there ->

Posted 25 May 2018 - 03:15 PM

But what if you're not making a layout manager? Then the other way is easier

What about a compromise: we do both

Edited by EveryOS, 25 May 2018 - 03:16 PM.


#12 Jummit

  • Members
  • 306 posts
  • LocationJulfander Squad Studio

Posted 25 May 2018 - 08:07 PM

globalWidget:repositionChild(wid, 5, 5)
If I would implement the reposition function in the parent, I would do it like this:
globalWidget:getChild(wid):reposition(5, 5)
This would also fix the issue Bomb Bloke pointed out:

View PostBomb Bloke, on 24 May 2018 - 10:16 PM, said:

I'd tell the child to move. Otherwise, what happens if you have children of children? You'd have to figure out parents of parents.

Edited by Jummit, 25 May 2018 - 08:07 PM.


#13 Luca_S

  • Members
  • 407 posts
  • LocationGermany

Posted 25 May 2018 - 09:53 PM

View PostJummit, on 25 May 2018 - 08:07 PM, said:

If I would implement the reposition function in the parent, I would do it like this:
globalWidget:getChild(wid):reposition(5, 5)
Tbh that doesn't really make sense because wid already is the child which was appended so globalWidget:getChild(wid) should return wid(If it returns anything else it would be pretty strange) and if it returns wid that would be the same as:
wid:reposition(5, 5)


#14 Jummit

  • Members
  • 306 posts
  • LocationJulfander Squad Studio

Posted 26 May 2018 - 07:46 AM

View PostLuca_S, on 25 May 2018 - 09:53 PM, said:

View PostJummit, on 25 May 2018 - 08:07 PM, said:

If I would implement the reposition function in the parent, I would do it like this:
globalWidget:getChild(wid):reposition(5, 5)
Tbh that doesn't really make sense because wid already is the child which was appended so globalWidget:getChild(wid) should return wid(If it returns anything else it would be pretty strange) and if it returns wid that would be the same as:
wid:reposition(5, 5)
Oh, I did something wrong there. I meant it like this:
globalWidget.wid = widget(1, 1)
globalWidget.wid:reposition(5, 5)






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users