This opinion is understandable, but based on the thinking that one needs to optimize their code to that degree
No, this is based on the thinking that I don’t want to clutter the tree with behavior/states. My point was: You don’t have to use nodes if you don’t want to.
Node objects are incredibly lightweight. When people come here with optimization problems, the answer is never that they have too many Node objects. The answer is instead they have too many objects on the screen at the same time, or are processing too many objects offscreen. And by too many, I mean 10s of thousands.
Yes, having too many nodes is rarely the issue. However, if you need to start optimizing, it can make sense to have a look at node processing overhead - it depends on the type of project.
It’s actually experienced programmers that more often need to be encouraged to use nodes. The reason being that they tend to overcomplicate their code because they future-proof. They are used to optimizing, and they think about it while architecting.
I don’t think that using more nodes helps you in making less overcomplicated things.
Early optimisation is an issue, but telling experienced programmers to use more nodes won’t prevent this.
Ah, finally a fellow node-adverse person. You’re not a big fan of autoloads as well, I presume. They are the supreme example of node abuse.
I’d rephrase this though into “… if you don’t need to”. If there’s is a functionality you need provided by a node, better let node’s fast native code handle it, instead burdening the system with more script execution.
Fair enough. As I outlined above, I personally feel that the benefits outweigh the problem of expanding and collapsing a single node in a tree. We will have to agree to disagree.
And my point was that if you need to start optimizing it’s not because you used Node instead of RefCounted or Object. It’s you have too much stuff on the screen. In which case the solutions are to either remove things from the screen, or use GDExtension and C++ to actually optimize your code.
That’s an oversimplified response to what I tried to explain in many, many paragraphs. There are often many unseen benefits to using Node objects that experienced programmers coming from other languages do not understand. And so they try to optimize by not using Nodes, when Nodes are already optimized to handle a lot of things.
Again, that’s an oversimplification of what I said.
I used to think that too, but they’re really freaking useful, and you like to optimize for fun (and are quite good at it).
Personally, I look at Nodes more and as components and have started using them as such. My Camera 2D Plugin is an example of that. If I want zoom functionality on a Camera2D, I just drop a Camera2DZoom component on it and I’m done. If I want to limit it to the bounds of TileMapLayer, I drop a Camera2DLimit component on it.
But I admit, my main goal in programming is reusability. You can do the same thing adding all the code to a Camera2D - which is where I started.
They’re useful when they’re useful, i.e. when you need persistent node functionality in the tree. However 99% of usage we see in the wild is for storing global data. You can do that equally well with static class members. Even the access syntax is the same.
As long as it’s not premature
I’ll take that as a compliment.
I don’t think I’m against using nodes or autoloads. People tend to overuse autoloads sometimes I guess. I guess I’m just trying to be pragmatic… and I think we shouldn’t rely on paradigms too much.
I never disagreed in the first place. It’s totally valid to want to use nodes for state machines. I just tried to offer a different perspective. It’s not like one way of doing this is more correct than the other
That’s an oversimplified response to what I tried to explain in many, many paragraphs
Sorry if I missed a nuance here. I had the impression that you wrote a lot just to emphasize these points.
