search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.55k stars 21.27k forks source link

Move math function to their own class #7983

Closed ficoos closed 4 years ago

ficoos commented 7 years ago

Currently there are a lot of math functions in the global namespace. It would be cleaner to move them to Math. Random. etc

Now that we're breaking compatibility in 3.0 anyway it might be a good chance to clean up the global namespace.

Zylann commented 7 years ago

Note these are built-in GDScript functions, just like type() or float() or funcref(). Also I wonder if there are any performance impact into moving these outside into a singleton.

eon-s commented 7 years ago

I know that GDScript was made to make games and is useful to get all the math functions on direct access but sometimes gets messy when you look for math only things and are mixed with the rest.

Not to mention that a change like this would break everything, even utility snippets...

I don't know what to think about this :sweat_smile:

bojidar-bg commented 7 years ago

I doubt if moving them into Math. would be good, though Random. is already covered by #7199. I'm doubtful because in JavaScript, all of it resides under a Math singleton, and it is not useful in cases when you want to use lots of math functions, and it doesn't make it much clearer otherwise. (log(2) is obviously some black magic, Math.log(2) is even more obviously the black magic).

karroffel commented 7 years ago

The singleton wouldn't be specific to GDScript though.

I have the new language options for Godot in mind. A Math singleton could be automatically generated. Currently it's required to implement these functions manually.

I'm not sure if that justifies such a singleton, but it's definitely worth a though as an alternative to the current "builtin"-philosophy

hubbyist commented 7 years ago

What about using a pseudo namespace to tag builtin functions in editor and remove all tagging at compile time. This will make things obvious and won't need any change to underlying structure. Obviously it will make parsing a little more complex but side effects will stop there.

bojidar-bg commented 7 years ago

On a second thought (provoked by #8085), I guess that's actually worth doing. Question is, as @karroffel said, should it be alternative to the current GDFunctions system, or should it fully replace it?

Zylann commented 7 years ago

If it's alternative then non-namespaced versions will still be there and it won't deal with the keyword conflict problem.

ficoos commented 7 years ago

There are a bunch of Singletons in the system already. Doesn't seem like it should be a problem to have a Math one.

bojidar-bg commented 7 years ago

Note that there is already the "Geometry" singleton anyway, so, indeed, we can have it in a singleton...

Also, note that doing this would remove most (2/3 approx.) from the @GDScript namespace, and would mean that other GD-only languages don't have to reimplement it (e.g. VisualScript) :smiley:

Zylann commented 7 years ago

Would this make math functions slower to call? Also, moving to a singleton would change the way they are implemented (currently a deterministic switch working exclusively on floats, having an influence on constants reduction eventually), and also this idea https://github.com/godotengine/godot/issues/8071 (if it gets approved).

Calinou commented 4 years ago

What's the consensus on this nowadays? I think this should be reopened as a proposal if there's still demand for it, so we can discuss the upsides and downsides of doing this for Godot 4.0.

Calinou commented 4 years ago

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!