get set vs properties, whether they are a good idea

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
DarkShroom
Citizen
Posts: 86
Joined: Mon Jul 17, 2017 2:07 pm

get set vs properties, whether they are a good idea

Post by DarkShroom » Fri May 18, 2018 10:24 am

I wanted to ask before i go ahead and think about adding properties to me game code

is there any explicit reason why love 2d itself does not use properties? is it perhaps because there is no way to reference 'self' without essentially copying curried functions into everything (functions that are embedded with the self reference

ie

Code: Select all

function () function2(reference_to_unique_object) end

for extra info about what i'm doing, i have created a object system where i have a reflected version of all the physics functions, it allows me to set the physics settings of an object before "activating" the physics (which creates the body, triangulates and adds the fixtures etc)... the reflected functions in the case of "fixture" for example, they run the same function on all the fixtures.... i wanted to abstract the physics system to i can turn it off and on and use the same variables to set things

User avatar
zorg
Party member
Posts: 2428
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: get set vs properties, whether they are a good idea

Post by zorg » Fri May 18, 2018 11:37 am

What do you mean by löve not using properities? I'm pretty sure both the Data and Object supertypes, and their subtypes both have tons of members, and getter and setter methods as well; case in point, SoundData has :getSample and :setSample, to name two.

As for whether it makes sense to use getters and setters, that depends on the coder, since by default, lua table access isn't really protected, so code could simply reference a member and either get or set the value that way, which is a more direct kind of thing than using accessor functions. (and as far as micro-optimizations go, probably just a tiny bit faster)
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.

User avatar
ivan
Party member
Posts: 1363
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: get set vs properties, whether they are a good idea

Post by ivan » Fri May 18, 2018 12:27 pm

zorg wrote:
Fri May 18, 2018 11:37 am
What do you mean by löve not using properities?
I think he means things like:

Code: Select all

src = love.audio.newSource("bang.wav", "static")
src.volume = 0.5
It's just syntactic sugar and would probably be slightly slower than using functions.
Note that the default Lua modules (string, math, etc) do not use "properties" either, except for "constants" like math.huge or math.pi.
is it perhaps because there is no way to reference 'self' without essentially copying curried functions into everything (functions that are embedded with the self reference
That's not necessarily true - if you are using metatables.

User avatar
raidho36
Party member
Posts: 1685
Joined: Mon Jun 17, 2013 12:00 pm

Re: get set vs properties, whether they are a good idea

Post by raidho36 » Fri May 18, 2018 1:35 pm

Why would that be slower? If anything, it should be faster, however trivial getters/setters are inlined and then there is no difference whatsoever. The practice of using getters and setters is useful when getting and setting a value does more than just changes its private variable, when it has some side-effects. If not, you might as well make those public and access them directly, there will be no difference, neither effective nor performance-wise - as previously mentioned... well, unless the runtime has to use vtables to figure out which function to call, and then it's a performance hit for no reason.

Love objects use getters and setters because they are light userdata, not actual Lua objects, so they don't have their own properties, only a metatable. If you implement a class, there's a good chance that using trivial getters and setters will be detrimental for performance, on account of having to do one extra table lookup and a function call. So if this sort of code goes anywhere near performance-critical section, testing will be very important to establish how it affects things. In general, I suggest treating Lua objects as structs with methods, and you don't need any methods to simply access a struct member.

DarkShroom
Citizen
Posts: 86
Joined: Mon Jul 17, 2017 2:07 pm

Re: get set vs properties, whether they are a good idea

Post by DarkShroom » Sun May 20, 2018 11:57 am

okay thanks for the information there, i read all the replies

so yes the syntactic sugar type properties, not the actual get/set functions... cool well i think i will go ahead then as it's something i like doing for the clarity of things

User avatar
ivan
Party member
Posts: 1363
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: get set vs properties, whether they are a good idea

Post by ivan » Sun May 20, 2018 2:11 pm

A while ago I worked on another game engine, similar to Love2D and it had "properties" as described above.
Although we did it using "tolua" from the backend, it's possible to program something like that using pure Lua.
For example, here's a one technique (thanks to grumps) that introduces "x" and ".y" properties:

Code: Select all

local b2d = debug.getregistry()
local reg = {
  func = b2d.Body.__index,
  x = b2d.Body.getX,
  y = b2d.Body.getY,
}
b2d.Body.__index = function(self, k)
  return reg[k] and reg[k](self) or reg.func[k]
end
As you can see, it's basically a waste of time.
Plus it can be confusing and harder to debug since you'll be running Lua code by using such "properties".
When you write "body.x" you would expect a table lookup not a function call - it may look pretty but it doesn't improve the "clarity" of the code.
So while it's possible, I don't recommend it unless there is a very good reason behind these "pseudo-properties".
Last edited by ivan on Sun May 20, 2018 2:20 pm, edited 1 time in total.

User avatar
raidho36
Party member
Posts: 1685
Joined: Mon Jun 17, 2013 12:00 pm

Re: get set vs properties, whether they are a good idea

Post by raidho36 » Sun May 20, 2018 2:15 pm

Well that's not actually properties, that's still functions wrapped in a dispatcher that makes the code look like it's properties.

And I imagine that's a hefty performance penalty for such minuscule amount of syntax sugar - not even any sort of useful feature.

User avatar
ivan
Party member
Posts: 1363
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: get set vs properties, whether they are a good idea

Post by ivan » Sun May 20, 2018 2:22 pm

Yes, like raidho said, you might as well use the Love2D API directly.

grump
Party member
Posts: 443
Joined: Sat Jul 22, 2017 7:43 pm

Re: get set vs properties, whether they are a good idea

Post by grump » Sun May 20, 2018 2:23 pm

I made a class implementation that supports properties via metatables.

Code: Select all

local Node = class {
[...]
	alpha = class.property({
		get = function(self) return self._color[4] / 255 end,
		set = function(self, value)
			self._color[4] = math.max(0, math.min(255, math.ceil(value * 255)))
			self:_invalidateColor()
		end
	}),
[...]

Code: Select all

node.alpha = 0.5
It's nice syntactic sugar, but it involves a small runtime overhead, and some more overhead when defining a class that is negligible IMHO. If OP is interested, I can post example code that shows how to implement it.
ivan wrote:
Sun May 20, 2018 2:11 pm
(thanks to grumps)
Thank you for the credits, ivans :crazy:

User avatar
raidho36
Party member
Posts: 1685
Joined: Mon Jun 17, 2013 12:00 pm

Re: get set vs properties, whether they are a good idea

Post by raidho36 » Sun May 20, 2018 5:30 pm

I wouldn't disguise a complex setter as a property. You might forget it was a setter with side-effects and then there will be a lot of futile bug hunting.

Post Reply

Who is online

Users browsing this forum: pgimeno and 5 guests