bell We have formed a new KEEP on class delegation and we a kotlinlang #language-proposals

🔔 We have formed a new KEEP on class delegation and we are looking for feedback (and a sheppard)! @Dico is the author: https://github.com/Kotlin/KEEP/pull/154

👍🏻 1

😁 1

orangy

09/26/2018, 10:43 AM

delegate val listDelegate: List<Int> = target

looks interesting, however it has an issue: since

listDelegate

can be accessed implicitly by calling into

List<Int>

methods on

this

, initialization order becomes a problem. When delegation expression is in the class header, you cannot sneak an

init

block or something else between initialization of this property and potential access (excluding well-known “leaking this” problem, e.g. accessing it from base class)

Dico

09/26/2018, 12:52 PM

That's a problem with the delegation pattern regardless of the syntax proposed being used. Current syntax has much bigger issues as explained in the file, and also suffers from the same problem. Programmer just needs to use their brain.

I touched on class initialization under Additional Notes

I agree that the problem you describe is more prominent when the programmer has control of the initialization order though. But do you think it's bad enough not to implement any of the approaches?

To clarify, it's a problem with the current syntax too because the superclass constructor is always called first.

orangy

09/26/2018, 1:29 PM

I didn’t say it’s “bad”, I just pointed out a problem that might need to be addressed.

Dico

09/26/2018, 1:30 PM

Right, sorry for misinterpreting.

Would an IDE Inspection be an option for that?

☝️ 1