-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Add better dynamic typing support for gdscript #3296
Comments
Though it does indeed require a script to be attached to the node, you can already do that with |
The main point of my suggestion is this would be either part of object or node
set and get don't do anything if the variable is undeclared |
I would recommend sticking to Object's |
You can implement whatever logic you want with
Well, the question was "If this enhancement will not be used often, can it be worked around with a few lines of script?", so I'm clarifying that yes, yes it easily can be. |
This can't be worked around without a script though that's my point. |
Your proposal is all about setting values of unknown types. I have no idea what PackedScenes have to do with this though, as PackedScenes are not a part of GDScript syntax.
If you only want to tag the object with a value, use meta, like Calinou has suggested.
That sounds like a lot of opportunities to create bad code and hard to catch errors. We can't stop people from shooting themselves in the foot, but we shouldn't make it trivial to do so. Keep in mind, that GDScript is dynamically typed, but it's not weakly typed. |
The PackedScene of the bullet when spawned is unknown. it could be Bullet it could be SomeTypeThatDoesn'tWork,
why though that's what variables are for.
Not bad code lua does it, java script does it. its a way of making sure something is there for the objects to use later.
Dynamically typed means not statically typed which means not compile time safe, |
I guess this feature is a combination or variables and meta data. |
|
What if we add a shortcut for metadata? |
Isn't it literally just a dictionary? Couldn't it just be exposed as such? Instead of |
It is indeed just a Dictionary, but my guess would be that it is not exposed directly for safety concerns, to avoid unexpected mutations. |
Can you elaborate? I'm not sure I understand. |
Objects are basically typed dictionaries in dynamic languages.
For one Godot is forcing people to attach script and declare variables on the object like it's statically typed which it's not. Second there is no reason to keep a meta table at all. variables in dynamic types languages can be created and typed at runtime, That's what makes them so great! Keeping it this way just adds for to more confusion.
Lets see here we have |
I just assume that if it was exposed as a property, it would be possible to change it in a way that is out of the control of the engine. And that for whatever reason it may not be desirable to allow that. After all, meta is used by the engine itself. |
I still don't get this example. If you have Allowing this pattern is essentially allowing variables to be used without declaration, which creates a multitude of opportunities to make mistakes without noticing. What if I have a code like this: var is_damage_enabled = true
var damage = 0
func add_damage(amount):
if is_damag_enabled:
damage += amount The user might be pretty confused when the Using
That's not really true. A lot of dynamically typed languages does not allow for monkey-patching objects at runtime like this. The ones that do allow it are usually criticized for it (such as Ruby and JavaScript).
If you want to use this feature you need to make sure it actually works like this, which requires reading the documentation anyway. Godot documentation has come a long way and those who think it's bad are probably just repeating what they heard 4 or 5 years ago. If the issue is the (lack of) documentation about metadata, that can be improved. |
Allowing this pattern is essentially allowing variables to be used without declaration, which creates a multitude of opportunities to make mistakes without noticing. What if I have a code like this: it requires a script and it requires checking that the spawned and collide object is of type bullet.
Using . is the same thing: easy to misspell and don't notice it. In this case it will only trigger at runtime (assuming you're not using static typing) but it still gives an opportunity to catch and fix the mistake. Also how is
That's not really true. java script for one is hated for far more reasons then monkey patching.
We shouldn't have to read the whole documentation top to bottom for every corner case Godot has. There have been many cases something has been buggy incomplete, undocumented or implemented it a way that if far from simple or easy to use. Again you are over looking the fact that.. Also no class_name doesn't work because it only uses the root of the scene and not the whole scene. |
Remember that using var a = 1
func _ready():
var b = 2
print(a) # 1
print(b) # 2 It's pretty handy. And if we allow the use of undeclared variables (especially if local ones too), then this will add some ambiguity, which will have to be solved in one of the ways:
func _init():
self.a = 1
func _ready():
b = 2
print(self.a) # 1
print(b) # 2 This is a more or less acceptable option. But any intermediate option will be unnecessarily confusing. And I generally dislike the idea of using undeclared variables. It seems to me that clarity is much more important here than flexibility. |
The point I am trying to make is it should be optional. (aka possible) I am just telling you what I needed as a user of the engine. But I still am still going to have to say I disagree |
Language scanner (I assume you mean a static analyzer) would not solve the issue. It could at most show a warning in this case, because it would never be able to tell whether you intended to declare a variable (or check if a variable exists) or it was a mistake. But if you do rely on this feature, there'll be a lot of warnings and you either would disable this type of warning or you would ignore them. It would still be an issue, especially for people not expecting this to happen. Not to mention that a static analyzer will always be slow and will have to be run on demand, so it's very easy to get this issue without any warning. Auto-completion don't solve it either because there are many cases where it's impossible to detect the type and thus list the possible member after the I don't think I know better than anyone. Not a single person would know what the whole community wants. But this proposal don't seem to be getting approvals from the community. While I don't disagree this would be helpful for your project (although I still don't get the initial example, which is already using a script anyway), there are definitely other ways to go about it that doesn't require this to be implemented. And I don't really like the idea of "static support is bad, then let's make it worse", as I don't think that's the proper way to go. Just because we can't detect all errors, it doesn't mean we should detect less errors that we already can. We should make it better for everyone instead. For the point of being optional, I'm not fond of it either. It just makes everything more complex: implementation, documentation, code samples. Very easy to get a tutorial and don't realize a particular option is enabled or disabled and because of that your code doesn't work. A beginner following the tutorial would have a hard time discovering what's wrong. If the community do want something like this, then we can discuss a good design to lessen the pitfalls. But it doesn't seem to be the case given the interaction with this proposal. |
Describe the project you are working on
Space ship game.
Describe the problem or limitation you are having in your project
Setting values on a node without needing a script on it or knowing what type it is.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
I love statically typed languages, but this is something GD script is not and never fully will be.
I suggest allowing something like this to be done..
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
This is a two step suggestion.
.
accessorThis allows..
Note undeclared variables do not show up in inspector.
If this enhancement will not be used often, can it be worked around with a few lines of script?
Not really we have static typing but it poorly supported right now and requires a script to be attached to the node.
Is there a reason why this should be core and not an add-on in the asset library?
Other dynamically typed languages allow this.
The text was updated successfully, but these errors were encountered: