этот код должен быть где-то вызван

так вот если метод вызывать до вызвова кода, который инежектит, то никакого объекта там не будет

это понятно. но как при наследовании это обойти?

часто самый простой способ обойти проблемы наследования это наследование не использовать

ну в данном случае не думаю что это хороший путь

мне вот что непонятно. почему не могло быть сделано так, что сначала устанавливаются фактические значения свойств из параметров конструктора и только потом вызывается конструктор базового класса?

тогда бы вообще этой проблемы не стояло. а так фактически котлин подталкивает к использованию свойств-параметров, так как удобно модно молодежно, но при этом мы получаем хороший способ выстрелить себе в ногу. если бы я по старинке использовал параметры и свойства бы устанавливал руками, то все было бы ок

а что с lazy init для пропертей? не о том?

тогда бы вообще этой проблемы не стояло. а так фактически котлин подталкивает к использованию свойств-параметров, так как удобно модно молодежно, но при этом мы получаем хороший способ выстрелить себе в ногу. если бы я по старинке использовал параметры и свойства бы устанавливал руками, то все было бы ок

Это вообще очень странно и неправильно. kotl.in/issue

Это вообще очень странно и неправильно. kotl.in/issue

что именно странно и неправильно? мое рассуждение или текущая реализация?

нет, вызывать конструктор до базового никак не возможно

нет, вызывать конструктор до базового никак не возможно

это что ограничения джава машины?

что именно странно и неправильно? мое рассуждение или текущая реализация?

Текущая реализация неадекватна. Наследник может полагаться на инициализированные поля суперкласса, это было бы нормально.

нет, вызывать конструктор до базового никак не возможно

Легко, можно его вообще не вызывать.

Текущая реализация неадекватна. Наследник может полагаться на инициализированные поля суперкласса, это было бы нормально.

в данном случае не инициализированы поля дочернего класса в момент работы конструктора родительского. просто потому что сначала работает родительский конструктор, потом дочерний, а поля выставляются там

то есть речь не идет о том, что в наследнике не доступны поля родителя, наоборот

в данном случае не инициализированы поля дочернего класса в момент работы конструктора родительского. просто потому что сначала работает родительский конструктор, потом дочерний, а поля выставляются там

А, тогда я неправильно понял. А с чего бы наследнику инициализироваться раньше?

чисто технически - ни с чего. но вот если он этого не делает, то код из родительского конструктора легко ломает все с NPE

стоит только из конструктора обратиться к методу дочернего класса, который использует поле-параметр

и это совсем не очевидно

очевидно что оно так будет работать, но не очевидно когда пишется наследник

чисто технически - ни с чего. но вот если он этого не делает, то код из родительского конструктора легко ломает все с NPE

Почему родительский конструктор ломается? Он зависит от наследника? Вызывает не-финальный метод?

в джаве так выстрелить себе в ногу нельзя - все поля класса железно инициализированы к моменту работы любого метода

Почему родительский конструктор ломается? Он зависит от наследника? Вызывает не-финальный метод?

да, он вызывает не финальный метод

ну или метод через рефлексию или через кодогенерацию, что не суть

да, он вызывает не финальный метод

Так же можно выстрелить и в Java, я думаю. Вызывать нефинальные методы в конструкторе как раз из-за этого и не рекомендуется.

хм

Так же можно выстрелить и в Java, я думаю. Вызывать нефинальные методы в конструкторе как раз из-за этого и не рекомендуется.

и что будет?

да, руками написанная логика в дочернем конструкторе не отработает и что-то может поломаться

и да это похоже, но в котлине как-то имхо менее очевидно за красотой и простотой проперти-пераметров

даже, если исходить из того, что в джаве тоже самое. почему нельзя в котлин классе сделать иначе? ведь требование в Java чтобы вызов базового конструктора шел первым связано имхо как раз с тем, что в дочернем конструкторе может быть произвольная логика, которая может обращаться к полям базового класса. но в данном случае мы точно знаем что наши параметры-поля - новые и что код их инициализации ничего тронуть не может в принципе

и что будет?

Here’s a subclass that overrides the overrideMe, method which is erroneouslyinvoked by Super’s sole constructor: public final class Sub extends Super { private final Date date; // Blank final, set by constructor Sub() { date = new Date(); } // Overriding method invoked by superclass constructor @Override public void overrideMe() { System.out.println(date); } public static void main(String[] args) { Sub sub = new Sub(); sub.overrideMe(); } }You might expect this program to print out the date twice, but it prints out null the first time, because the overrideMe method is invoked by the Super constructor before the Sub constructor has a chance to initialize the date field.

Так же можно выстрелить и в Java, я думаю. Вызывать нефинальные методы в конструкторе как раз из-за этого и не рекомендуется.

Таки да, вызов non-final методов из конструктора крайне не рекомендуется и дело тут не в Котлине (собственно это хороший способ выстрелить себе в ногу) Пример: http://www.informit.com/articles/article.aspx?p=20521

Here’s a subclass that overrides the overrideMe, method which is erroneouslyinvoked by Super’s sole constructor: public final class Sub extends Super { private final Date date; // Blank final, set by constructor Sub() { date = new Date(); } // Overriding method invoked by superclass constructor @Override public void overrideMe() { System.out.println(date); } public static void main(String[] args) { Sub sub = new Sub(); sub.overrideMe(); } }You might expect this program to print out the date twice, but it prints out null the first time, because the overrideMe method is invoked by the Super constructor before the Sub constructor has a chance to initialize the date field.

да, тут я согласен, это таже проблема.

но код инициализации полей-параметров ведь МОЖЕТ быть вызван технически до кода из базового конструктора, разве нет?

то есть либо это недоработка компилятора, либо какое-то техническое ограничение, которое я просто пока не понимаю

но код инициализации полей-параметров ведь МОЖЕТ быть вызван технически до кода из базового конструктора, разве нет?

Код инициализации — это такой же код конструктора, как и код в init.

Код инициализации — это такой же код конструктора, как и код в init.

с тем исключением, что компилятор может гарантировать его необращение к данным базового класса

значит конкретно этот код может и должен имхо быть размещен ДО вызова базового конструктора

тогда такой выстрел в ногу будет невозможен

Насколько помню до завершения вызова конструктора формально объект еще не сформирован, потому даже для final поля можно увидеть непроинициализированное значение (все это из-за вызова методов из конструктора)

с тем исключением, что компилятор может гарантировать его необращение к данным базового класса

тут вопрос не в компиляторе, а в том может ли такое гарантировать JMM

с тем исключением, что компилятор может гарантировать его необращение к данным базового класса

Как раз наоборот, можно обращаться к данным базового класса. open class Base { val size = 10 } class Big : Base { val actualSize = 5*size }

Как раз наоборот, можно обращаться к данным базового класса. open class Base { val size = 10 } class Big : Base { val actualSize = 5*size }

мы же говорим про параметры-свойства а не про любые свойства

или хочешь сказать что это будет неконсистентно если свойства будут инициализироваться в разных местах?

но имхо параметры это такая, важная, штука. через них же DI делают и вообще много всякого важного могут передавать. даже если только их обезопасить - уже хорошо

мы же говорим про параметры-свойства а не про любые свойства

Инициализация чего бы то ни было — это действия, которые должны выполняться сначала у родителя, затем у потомка.

Инициализация чего бы то ни было — это действия, которые должны выполняться сначала у родителя, затем у потомка.

на чем основано это утверждение?

на чем основано это утверждение?

На поведении Java, и, за нею, Kotlin.

На поведении Java, и, за нею, Kotlin.

но в джаве нет параметров-свойств - там в принципе нет такой семантики. код в конструкторе в джаве - по определению произвольный и написан программистом, никакой своей магии компилятор не добавляет

но в джаве нет параметров-свойств - там в принципе нет такой семантики. код в конструкторе в джаве - по определению произвольный и написан программистом, никакой своей магии компилятор не добавляет

Почему семантика свойств должна изменить это поведение?

/* можно переопределить get() так, чтобы он не зависил от инициализированности :) */

потому что свойства это парметры смешанные с неким кодом их установки в поля класса. а значит есть некий код, который дописывает за тебя компилятор и значит к нему не применимо это требование (если он не использует данные базового класса)

/* можно переопределить get() так, чтобы он не зависил от инициализированности :) */

вот эту фразу не понял, поясни плз

потому что свойства это парметры смешанные с неким кодом их установки в поля класса. а значит есть некий код, который дописывает за тебя компилятор и значит к нему не применимо это требование (если он не использует данные базового класса)

Не сказал бы, что этот код дописан. Просто есть установка данных в параметры. Но это я уже прицепился к терминологии.

ну да, но это новая штука которой не было в джаве

Про что вообще спор?

Есть данность изменить которую не в наших силах

вот эту фразу не понял, поясни плз

class Sub : Super { val i = 100500 // из конструктора суперкласса видно 0 override fun getNumber() = i }class Sub : Super { val i: Int get() = 100500 // из конструктора суперкласса видно 100500 (ну, я так думаю) override fun getNumber() = i }

Есть данность изменить которую не в наших силах

почему? вдруг в 1.2 сделают? =)

Да и смысла нет. Реализация наследования вполне норм. Этот механизм вообще сложный, потому и кучку подводных камней имеет

в джаве так выстрелить себе в ногу нельзя - все поля класса железно инициализированы к моменту работы любого метода

Сказали же уже выше, что это не так

Спор почему JMM работает именно так, а не как удобно мне

почему? вдруг в 1.2 сделают? =)

Конечно не сделают. То как есть это лучшее из того на что можно рассчитывать

почему? вдруг в 1.2 сделают? =)

Кстати, а что нам ждать в 1.2?

Сказали же уже выше, что это не так

я уже и согласился выше =)

ERROR: S client not available

Кстати, а что нам ждать в 1.2?

Багфиксинг

Это в 1.1.1

Конечно не сделают. То как есть это лучшее из того на что можно рассчитывать

мне интересно почему. не спора ради, а реально понять с чем связано такое ограничение.

Kotlin Native - 1.2?

Это не ограничение

Тут вот нам 15 марта обещают расскзать про kotlin 2.0

Это то как работает наследование

Кстати, а что нам ждать в 1.2?

не экспериментальные корутины?)

не экспериментальные корутины?)

Это не интересно (эксперементальных хватает) А вот алиасы на пакеты (как в scala) - этого не хватает.

Это не интересно (эксперементальных хватает) А вот алиасы на пакеты (как в scala) - этого не хватает.

А для каких кейзов это надо?

Легко, можно его вообще не вызывать.

Нельзя. Так как в Джава если не вызвать либо super(), либо this() явно, то компилятор самым первым вызовом неявно подставит super()

А для каких кейзов это надо?

Перед скалистами понтаваться ? конечно

И еще тайп классы можно (вон в C# тоже об этом думаю)

Нельзя. Так как в Джава если не вызвать либо super(), либо this() явно, то компилятор самым первым вызовом неявно подставит super()

Конечно не вызвать конструктор родителя нельзя. На этом вообще строится вся консистентность наследования

Нельзя. Так как в Джава если не вызвать либо super(), либо this() явно, то компилятор самым первым вызовом неявно подставит super()

Речь о компиляторах, соответственно, и заявление на уровне байт-кода.

Речь о компиляторах, соответственно, и заявление на уровне байт-кода.

+1

речь не о концепции наследования для программиста и не об ограничениях/правилах которые накладывает компилятор на него. речь о реализации компилятора

Это не байткоду противоречит, а смыслу наследования

Это не байткоду противоречит, а смыслу наследования

ну это как посмотреть. ведь сам дочерний объект в памяти уже создан в момент вызова конструктора базового класса. что мешает и часть полей инициализировать к этому моменту? кстати в джаве дефолтные значения поля дочернего класса получают до вызова конструтора базового класса. что тоже можно расценивать как аналогичное нарушение наследования

ну это как посмотреть. ведь сам дочерний объект в памяти уже создан в момент вызова конструктора базового класса. что мешает и часть полей инициализировать к этому моменту? кстати в джаве дефолтные значения поля дочернего класса получают до вызова конструтора базового класса. что тоже можно расценивать как аналогичное нарушение наследования

Раз уж зашли на такой уровень, создание объекты и вызов конструктора — две разных инструкции :)

Раз уж зашли на такой уровень, создание объекты и вызов конструктора — две разных инструкции :)

ну так и я о том же. ничего не мешает между ними еще какие-то инструкции засунуть =))

наследование и без того механизм очень сложный, чтобы с ним хоть как-то иметь возможность иметь дело нужны очень строгие правила работы этого механизма. Опять же когда проектируешь базовый класс, ты хоть в чем-то должен быть уверен -- например в целостности данных базового класса, поэтому есть недвусмысленная последовательность инициализации класса и его предков

а засунут-то конечно можно куда угодно что угодно

хоть пиши компилятор, который убивает систему при запуске

но насколько я представляю у котлина другие цели

Это не интересно (эксперементальных хватает) А вот алиасы на пакеты (как в scala) - этого не хватает.

? да, ради этого нужно

? да, ради этого нужно

Ну рили я уже это объяснял, вот тут это поднималось https://discuss.kotlinlang.org/t/imports/1571/4

Ну рили я уже это объяснял, вот тут это поднималось https://discuss.kotlinlang.org/t/imports/1571/4

а чем это отличается от того, что уже есть? import bar.Bar as bBar // bBar stands for 'bar.Bar'

Тем что нужно руками прописывать каждую зависимость (плюс скоуп функций плохо понимается без доп. квалификатора).

https://github.com/icela/FriceEngine-DSL#simplest

Закинули в котлин линк)

1. Взяли стиль лого JB 2. код на китайском