Closed Mercerenies closed 2 years ago
Oh, hey, this issue is still open.
I implemented this a few hours after opening the issue, over in 811de09981638e1569f45e071f4a6f3f60383234. This issue is closed now. Bye bye.
Oops! I misunderstood. @
is implemented, but not the sugar on constructor args. Re-opening :)
Done as of 3f5f74e
(defclass Foo (Reference) main
(defvars x y z)
(defn _init (@x @y @z)))
The above code compiles to
extends Reference
func _init(x_0, y_1, z_2):
self.x = x_0
self.y = y_1
self.z = z_2
var x
var y
var z
static func run():
return null
Important note: There are several things fighting for control over the initializer right now. These things happen in the following order.
super
call.defvar
but whose initializers are too large to compile to GDScript expressions are initialized.@foobar
arguments (i.e. this issue) are assigned to their argument value.The reasoning for this is as follows.
defvar
are intended to be simple and independent. If the defvar
is complicated, it should be in the constructor explicitly anyway.For a display of all of these in order, see the test called closure_and_init_args_lambda_class_test_2
.
Coffeescript has a neat little feature where you can declare arguments prefixed with an
@
and they'll get assigned to relevant instance variables. I think this could be really useful in GDLisp constructors. i.e. my suggestion is to allowto be equivalent to
Consider whether we want to restrict this behavior to constructor functions or try to extend it to all GDLisp functions. It can be theoretically useful in other functions, but at the same time it complicates lambda list parsing for all functions instead of just constructor functions (which, right now, use simple lambda lists, since constructors are instance methods and don't support optional/rest arguments)