From: Jean Privat Date: Sat, 21 Feb 2015 06:04:31 +0000 (+0700) Subject: Merge: class annotation `autoinit` to explicitly lists initializers. X-Git-Tag: v0.7.2~12 X-Git-Url: http://nitlanguage.org Merge: class annotation `autoinit` to explicitly lists initializers. A suggestion of @Morriar is to use a class-level annotation `autoinit` to list initializers. It should ne rarely used, in case of conflict for instance, or to restrict the number of initializers (but this could be fragile). A step towards #785 ~~~nit class A var a: Int var b: String end class B autoinit c, b, a super A var c: Bool end var a = new A(10, "foo") var b = new B(true, "foo", 10) ~~~ Some issues remains, I my require your input on these * why I am required to put `autoinit` before the `super` clause? because the grammar is ugly. Maybe I should find a way to enable the `autoinit` clause everywhere in the body of the class? This is a grammar issue that can be solved independently I think. * what are the validity of initializers? The first commit is used to discriminate properties that are initializers and those that are not. I am not sure if restricting what can be used an initializer makes sense. In fact I really do not know what is the best expressive-but-safe policy here. See the last point for a related issue * what about clearing the full list of initializers (so no parameters in the new)? The annotation `noautoinit` will do the trick. * what about setters? when one writes `class A var x: Int`, in fact the initializer is not the getter `x` but the setter `x=`. It is obvious once one understand that `var a = new A(10)` is just `var a = alloc A; a.x = 10; a.init`. However, I chose to implicitly try to search the setter first when given `x` as an element of the `autoinit` clause, so that one can write `autoinit x` instead of the less POLA `autoinit x=` (that also works by the way). Unfortunately this kind of heuristic makes the specification more complex, but also prevents one to use a method `x` as an initializer if a method `x=` exists. Pull-Request: #1158 Reviewed-by: Lucas Bajolet Reviewed-by: Alexandre Terrasa --- 31ade8fa569ee0d49b948aa6157d1f984f7ed435