Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow implicit property typing with new properties #1880

Closed
Shadowblitz16 opened this issue Nov 23, 2020 · 7 comments
Closed

Allow implicit property typing with new properties #1880

Shadowblitz16 opened this issue Nov 23, 2020 · 7 comments

Comments

@Shadowblitz16
Copy link

Shadowblitz16 commented Nov 23, 2020

Describe the project you are working on:
NetworkTest

Describe the problem or limitation you are having in your project:
Nothing but looking at the godot 4 properties makes me want to commit sudoku

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
currently I like the new properties the only issue with them is we have to do this..
var property: set(value): return value #<-value?

I suggest for a optional implicit value keyword when (value) is not supplied with autocompleate

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

#valid
var _property 
`var property:
    set(value): _property= value
    get: return _property
#also valid
var _property 
var property:
    set: _property = value
    get: return _property

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Its less typing so it would probably be used more then the current version and no

Is there a reason why this should be core and not an add-on in the asset library?:
properties are used quite often and having to type (value) for every one is an extra 7 characters and is honestly ugly in my opinion

@vnen
Copy link
Member

vnen commented Nov 24, 2020

properties are used quite often and having to type (value) for every one is an extra 7 characters and is honestly ugly in my opinion

"Ugly" is subjective. Code is read more times than it's written so in general I prefer to improve readability even if you have to type a bit more.

@KoBeWi
Copy link
Member

KoBeWi commented Nov 24, 2020

Doesn't set(v): _property = v work? It's shorter.

@Shadowblitz16
Copy link
Author

Shadowblitz16 commented Nov 24, 2020

@vnen Thats why the value keyword would be highlighted in that case

@KoBeWi
I mean it is shorter but I still think it looks ugly.
It misaligns the setter and getter which triggers my OCD really bad

Also if lambdas ever get added it would look more natural.

var _property 
var property:
    set: => _property=value
    get: => _property

opposed to

var _property 
var property:
    set(value): =>_property=value
    get: =>_property

It more of a preference issue and I think it should be optional

@akien-mga
Copy link
Member

Godot and GDScript are explicit by design, I'm against this proposal.

Giving a name to the parameter is good. Whether you think it's ugly is not relevant, you have hundreds of functions with named parameters too and they don't seem to be a problem.

@katoneko
Copy link

Also see #844 and the number of thumbs down on this comment in particular which gives a pretty good idea that people voted against this. So is there any point in repeating the discussion, knowing it would meet the same conclusion?

@Shadowblitz16
Copy link
Author

Why is having the option a bad thing?
It would be completely optional

@aaronfranke
Copy link
Member

Also see #844 and the number of thumbs down on this comment in particular

Haha, yes :) but first see this comment.

I still think this can be a good idea, it's what C# does and it works fine there. To me it's clear enough.

However, this won't happen due to the amount of people against this, so I'm closing this. Besides, the worst that could happen is that the code is a bit more explicit than necessary... which isn't all that bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants