Godot: Should we keep the `z` property in Node2D? (naming)

Created on 26 Dec 2017  路  10Comments  路  Source: godotengine/godot

Godot 3.0

In Node2D, there is a property named z. When used, this property overrides the drawing order of the node. So far, so good.

However, in Godot 3.0 properties became first-class reserved names in scripts, which means any script inheriting Node2D & cie will be unable to use z for any variable, be it member, parameter or even locals.

I know good practice about naming variable names, but that one's name is either way too good, or just awful (depends on view point considering good practice xD), but I think it should be renamed, especially when you consider inheritance, and it's not used that much in scripts, in general, to the point of being a one-character variable.

Could it be renamed z_order? (now is the best time, 3.0 is still beta)

enhancement core

Most helpful comment

If it's ok for you, I have a ready commit for this :

image

All 10 comments

What about depth? I don't like z_order because to me an "order" is a global object, defining the ordering relation between different elements.

It's a good idea to rename this, can be boring to don't allow to use z as a variable.

To visualize a bit :
image

In Libgdx (which is for me a clean code and good named) it's ZIndex. In Phaser it's renderOrderID. In OpenGL we are rahter talking about GL_DEPTH_TEST...

For me, both z_order, z_depth or z_index can be used.

I like z_index or z_depth

I like z_index, or we could be more explicit and actually call it draw_order on Node2D. ZIndex might also be more familiar terminology with those who use CSS frequently.

If it's ok for you, I have a ready commit for this :

image

Modification is ready to be checked and merged.

Do you know if an issue listing all breaking changes from 2.1 to 3.0 exist ? I must add this one !

Fixed by #15191.

reserved names in scripts, which means any script inheriting Node2D & cie will be unable to use z

this is untrue. unless that script is using the letter z (and not a public member variable).

why are we continuing to make silly syntactical changes over use-cases that don't exist (or extremely rare)? this makes it harder for people transitioning from 2.0 and previous versions to 3.0

@girng it used to be true, name lookup was changed, which is why this issue is now closed

i see. maybe i misread issue, my bad. i thought we had to do the opposite

Was this page helpful?
0 / 5 - 0 ratings