LÖVE

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
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

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)

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: 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.

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.

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

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: 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".

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.

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

I made a class implementation that supports properties via metatables.
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

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.