Improve default value setting in RegisterProperty and RegisterSignal annotations
chippmann opened this issue · 5 comments
Describe the problem or limitation you are having in your project:
Currently it's very cumbersome and not typesafe to define default values. On top of that, the user in most cases defines a default value in code anyways for properties. And for signals it wpould be easy as well.
Describe how this feature / enhancement will help you overcome this problem or limitation:
The user can use kotlin default value features for registering signals and normal initialisation for properties instead of an usafe string.
Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
The user would write just this to register a property with a default value:
@RegisterProperty(visibleInEditor = false)
val someProperty = "I'm an awesome String!"
and this for Signals with default values:
@RegisterSignal
fun someSignal(firstArgument: Boolean = false, secondArgument: String = "coolStuff") {}
Describe implementation detail for your proposal (in code), if possible:
We need to find a way to get the values of the properties and parameters inside the entry generation code generation in a typesafe way.
If this enhancement will not be used often, can it be worked around with a few lines of code?:
Yes we could just use the current string version but it's ugly and not typesafe at all
Is there a reason why this should be in this project and not individually solved?:
Entry generation is part of the core project.
I don't know if this can be done in the same PR or not. But something nice would also to have our own ExportHint class.
propertyHint = PropertyHint.Range, hintString = "0,100000,1000,or_greater" is prone to errors easily.
Instead we could have multiple ExportHint child classes and write:
propertyHint = RangeHint(0, 100000, 1000, RangeOption.OR_GREATER)
This can be done but those need to be enums.
I will add those as well :-)
If you have time, I would be really thankful if you could list the strings here.
I will make a separate issue for the property hint strings as they will probably introduce completely new annotations and not some sort of enums.
Closed in favor of new implementation in master-merge for new binding