Describe the project you are working on:
My project has a GUI containing a large number of inter-operating custom controls and related logic modules. There is a need for the various controls and logic modules to inter-communicate. Many controls need to implement the same methods but with different logic.
Describe the problem or limitation you are having in your project:
Due to parser cyclic reference errors I'm using call-groups as a way for the GUI controls and logic modules to intercommunicate. For example, my game has "power", "engines", "weapons" and several other "systems". All of the systems have a power button. When the power system's power button is pressed all other systems are notified of the event. This is done using call_group("pwr","pwr_mstr_pwr_btn_pressed"). Every system must implement the method to receive group call. However, each system has unique logic associated with the master power button press.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Add support to GDScript for method prototypes. There may be a need to also indicate a class is virtual/prototype so the parser/runtime will raise an error only on concrete classes.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Possible options:
prototype func_name(arg:int)->String;
virtual func_name(arg:int)->String;
mustoverride func func_name(arg:int)->String;
If this enhancement will not be used often, can it be worked around with a few lines of script?:
The only work around I have found is to implement methods in base classes to programmatically check that required methods are implemented by descendant classes. This is a crude and rather ugly solution prone to errors and difficult to maintain.
Is there a reason why this should be core and not an add-on in the asset library?:
Not sure if it can be implemented as an add-on.
With the new GDScript syntax, this would be better implemented as an @virtual annotation rather than keywords.
We could also replicate the @const and @override annotations as used in the C++ API. (const is for methods that can't change the instance's member variables, override is for methods that must override a base class' method.)
Most helpful comment
With the new GDScript syntax, this would be better implemented as an
@virtualannotation rather than keywords.We could also replicate the
@constand@overrideannotations as used in the C++ API. (constis for methods that can't change the instance's member variables,overrideis for methods that must override a base class' method.)