Write this() instead of constructor()

hello, everyone,
could you, please, consider adding “this” for writing constructors instead of writing “constructor”, i.e.:

class CustomImageView : ImageView {
this(context: Context) : super(context) {
}
this(context: Context, attrs: AttributeSet?) : super(context, attrs) {
}

}

P.S.: i saw that in D lang. But after writing “constructor” i thought “this” would be ok, since “init” is already used

Why exactly would this be an improvement? We have to keep constructor in order to keep backwards compatibility, and having synonyms for keywords typically adds nothing more than confusion.

1 Like

from my experience of using kotlin it seems not ok to write constructors right after class names(the more parameters constructors have, the worse readability of code), but typing each time “constructor” is not good as “constructor” is a long word, so i thought it would be good to use “init”, but “init” is already used, i can’t write something like:
init(context: Context) : super(context) {
}
init(context: Context, attrs: AttributeSet?) : super(context, attrs) {
}
But from the other point, i could write something like:
constructor(context: Context) : this() {
}
so why not to write like:
this(context: Context) : this() {
}

so i suppose you added “constructor” keyword, because you couldn’t use “this” for some reason, because writing code like:
this(context: Context) : this( ) {
}
would lead to some problems in parsing code, because you already use “this” keyword in many places\cases.
Am i right?

It’s not because of parsing problems, it’s because a language generally is easier to understabd when different concepts (a constructor and a reference to the containing class) are referenced by different keywords, not the same one.

And “why not?” is not how language design works. Any new feature, and even more so any change to an existing feature, requires fairly strong arguments showing how the existing design fails to solve some problems that occur when trying to use the language.

3 Likes

and what was the improvement of adding “constructor” keyword instead of reusing “this” or “init”?
Now i have to write “constructor” instead of writing “this” or “init” ))) i dont see it as an improvement at all)))

Once again: because these mean different things. this is reference to the instance of the containing class. init is a block which is executed in any constructor. constructor introduces a constructor.

And thankfully modern editors and IDEs support code completion, so the number of letters in the ‘constructor’ keyword doesn’t really make it harder to use.

so, how other languages use “this” or “init” as a constructor?))) Answer: language designers simply use these words, and simply say in lang docs that “this” or “init” is used to write constructor))) And this is how you did to “constructor”: you simply added the keyword and wrote in docs that “constructor” is used to write a constructor)))

i even wouldn’t need code completion in that place where i could simply type “init()” or “this()” )))

Yes, language design involves making decisions, and designers of different languages make different decisions. I’ve explained why we made the one we did.

thank you for explanation!

Compared to java it is a huge improvement. With Java you had to use the name of the class which can be quite lengthy.

Kotlin also appears to be designed with the idea in mind that while writing code is important, reading code is even more important. Constructor is a bit long, but very readable. It isn’t as long as to really hamper readability. It doesn’t add noise (like trivial getters/setters do). Overall Kotlin is quite readable, and code is read much more frequently than written or changed. Also remember that clear, easy to read, code is much more likely to be correct.

1 Like

True. Compared to java, constructor keyword is far better. My Java class names represent the whole idea of the class’ purpose which will get it to even more lengthier. The java constructors will really look awkward then. I had to use injection instead of constructor arguments. Luckily Kotlin has same common keyword constructor for all these.

anyway init or this are shorter and mean the same as constructor;
in kotlin this is already used in something like: constructor(i:Int) : this() {}
so the idea is simple: this(i:Int) : this() {}

No, they mean very different things. Giving them an additional meaning that means declare a constructor just adds confusion. The fact that constructor is longer than this is unimportant. It is at least unambigous it is only used to declare a constructor. And in practice you usually don’t even need the constructor keyword. You only need it if you are declaring multiple constructors (which is not often needed due to default parameters and the ability to create factory methods in a companion object) or when you need to add an annotation to the constructor.

If you cannot see how bad and confusing that syntax would be then I am at a loss how to convince you.

i actually use constructor keyword because primary constructor in kotlin looks like a bad idea. Separating constructor from class declaration looks good for readability.

even if it needs to write only one constructor, i write constructor(), i,personally, avoid writing kotlin’s primary constructors

kotlin prevents writing more than one constructor with the same signature; at first glance, the code looks strange as one got used to reading this in the cases of accessing properties\fields of objects of a class, but then it looks logical to write constructors using word this because this means an object of the class.

It’s not a bad idea. If you don’t want to use it that is your choice, but it is more readable usually to use it unless you have complex initialization requirements.

That is pretty much a Java thing and a basic concept. How can you have multiple constructors with the same signature?

So accessing properties/fields of the class has nothing to do with declaring a constructor. There is no logical reason to associate it with declaring a constructor. It is used to call one constructor from another, but that is totally different than declaring a new constructor.

actually, it has from the point of: 1. reusing already existing this keyword; 2. shrinking number of letters to write; 3. shrinking number of letters to read

yes, and you have written the key thing: “to call one constructor”; one understands, that this() means calling a constructor(and one doesn’t see it as a bad idea), but one, for some reason, avoids the fact, that this can be used both for calling one constructor from another and for declaring constructors in general and for accessing properties\fields of class instances(objects). So using this has multifaceted sense, so it can be seen from many points of view