funikovyuri
причина - проблемы реализации множественного наследования.
Извини, но это называется слышал звон... Единственное на что повлияло наличие множественного наследования так это на необходимость указывать все суперклассы по имени (вместо super или base).
Далеко не только на это. Последствия множественного наследования очень сложны и запутанны.
Думаю, ты понимаешь причину ошибки "объект не инициализирован", которая будет зафиксирована, если ты попробуешь, например, передать параметром super поле класса.
В случае множественного наследования - объект может быть "частично инициализированным". Соответственно, логика усложняется, появляются вопросы, на которые нет разумного ответа. Скажем (из головы): идет наследование "ромбом" (то есть от класса А унаследованы B и C, от B и C унаследован D). В A есть некоторое поле. Будет ли оно считаться "инициализированным", если вызван конструктор B, но еще не вызван конструктор C? Если нет - почему оно доступно в конструкторе B, но недоступно после конструктора B? Если да - почему полем объекта-предка можно крутить до вызова конструктора (последнего конструктора) этого объекта-предка?
Промежуточные выкладки - еще более усложняют логику в этом месте.
Конечно, можно принять какую-то схему разрешения подобных вопросов - но она будет недопустимо сложной. Именно поэтому - или, точнее, в том числе и поэтому - приняли решение выделить, по сути, отдельный, принудительно упрощенный блок инициализации. И в данном случае это совершенно правильное решение.
funikovyuri
В джаве это - не обусловлено совершенно ничем.
Угу, я уже писал чем это обусловлено. Конструктор - это НЕ виртуальная функция
Виртуальность конструктора совершенно не при чем. Ты упираешь на виртуальные конструкторы дельфы - но они вовсе не обязаны быть виртуальными. В дельфе они
могут быть виртуальными - не более того. Единственное отличие - дельфа разрешает доступ к полям объекта до вызова конструктора предка. Что, может быть, неидеологично - не буду спорить.
Конструктор - практически обычная функция, основной особенностью которой является "неинициализированное" состояние объекта на входе. Поэтому компилятор совершенно справедливо блокирует действия с этим объектом, да и справедливо не дает вызвать конструктор инициализированного объекта - тут дельфа действует хуже.
Что касается локальных переменных и внешних объектов - манипуляции с ними до инициализации ничуть не страшны. Рассмотри следующий псевдокод:
1.
2.
3.
4.
5.
6.
7.
8.
// --> вызов new
выделить память
выполнить/инициализировать статики
инициализировать поля суперкласса
// --> практически, здесь начинается конструктор
вызвать/выполнить тело конструктора суперкласса
инициализировать поля класса
выполнить тело конструктора класса (тело - то, что без супера)
Давай предположим, что "тело конструктора суперкласса" вычисляет какую-нибудь локальную или глобальную переменную. Имеет право? Имеет.
Вопрос: что изменится (с точки зрения среды выполнения, реализации), если это вычисление выполнится не внутри тела, а непосредственно до него?
Таким образом, по реализации вопросов нет. Что касается идеологии - идеологично было бы запихнуть конструктор туда же, куда и в C++. Или - реализовать выполнение похожим на общую логику выполнения программного кода.
А так - унаследовали глупость из C++, назвав ее "упрощение синтаксиса".
funikovyuri- ни в C++ ни в C# ни в java... И еще - конструкторы ВСЕГДА выполняются в строгом порядке от суперкласса к подклассу!
И что из этого?
funikovyuriПоэтому ты и не можешь написать свой код - так как когда выполняется код из super - твое присвоение еще не отработало!
Давай разберем тут чуть поподробнее. Ниже я напишу код и псевдокод, в который он компилится:
1.
2.
3.
4.
5.
6.
7.
8.
public MyObject ( int i) {
super (i+ 1 );
// .....
}
// псевдокод:
// internal_variable = i + 1
// super (internal_variable)
И вот теперь объясни - почему следующий код нельзя трактовать как следующий же псевдокод:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
public MyObject ( int i) {
int j = i + 1 ;
super (j);
// .....
}
// псевдокод:
// internal_variable = i + 1
// super (internal_variable)
// int j = internal_variable
funikovyuriПросто в sun решили упростить синтаксис и убрать список инициализации как отдельную языковую конструкцию - и все - надо смотреть в корень.
Давай смотреть в корень. Суть твоего объяснения - в том, что код { some_action; super(); ... } реально должен был бы быть выполнен как { super(); some_action; ...} - потому что super() фактически, как и в C++, выполняется в отдельном блоке инициализации класса, до "тела конструктора", которые ты пишешь.
Это так. Но ты называешь это упрощением синтаксиса? Лично я полагаю это неуместным запутыванием ситуации.
funikovyuriТы говоришь, что знаешь еще 10 языков, в которых принято другое поведение
Цитату, пожалуйста.
funikovyuri- я знаю только один - это VFP - да и то просто в силу виртуальности ВСЕХ методов его классов.
Да при чем тут виртуальность?
В дельфе виртуальность конструкторов проявляется только в одном: можно написать конструкцию, аналогичную следующему а-ля java-коду:
1.
2.
Class myClass = MyObject.getClass();
Object myObject = myClass. new ();
и при этом будет вызван конструктор класса MyObject (если он виртуальный).
В джаве ты делаешь абсолютно то же самое через newInstance - разве что в дельфе ты при этом можешь еще и передать параметры, а в newInstance, если не изменяет память - нет.
funikovyuriЯ никогда не писал на pascal'e, а ты видно на C++.
Увы, мимо - я писал на C++.
funikovyuri- без указания их классов используется конструкция
try { Something; } catch (...) { SomethingWrong; }
В C++ - да. А что, мне пора обновлять компилятор? Этот код откомпилируется в джаве? Или все-таки в джаве приходится писать catch (Throwable t)?
funikovyuri-
и мне, например, она кажется более наглядной чем вариант pascal'я
Хм. Ты предлагаешь перейти к сравнению паскаля с C++? Не хотелось бы.
Лично мне - нравится вообще без всего, но это вопрос привычки. Вариант "как в C++" меня в целом устроил бы. Но в моем компиляторе такое не проходит. И в руководствах тоже вроде не упоминался такой вариант.
funikovyuriПонимаешь - ты сам своим тоном вынуждаешь отвечать жестко. С самого начала ты не расположен дискутировать.
Понимаешь ли, ты подключился к разговору с середины. Начался он с того, что некто покинувший нас начал говорить образцово неграмотные глупости про дельфу - почему я и начал "отвечать ему жестко". На что-то ты ответил со стороны, на что-то, вероятно, я отвечал, где-то перенеся на тебя общий фон разговора. За последнее, если было так - прощу прощения.
funikovyuriНапример, пишешь про конструкторы в С++, и при этом используешь фразу про "проблемы реализации множественного наследования" - ну и какие там проблемы с его реализацией?
Кажется, расшифровал. Впрочем, если тебя не устроит такая версия - можем продолжить обсуждение или зафиксировать несогласие.
На самом деле я больше не уверен в некоторых других своих словах - например, в том, что в JDK 1.5 не появилось таки нормальной табличной модели для ResultSet-ов.
funikovyuriТак зачем же так писать? и так везде - тебе вообще не кажется, что критиковать такую платформу как java по синтаксису catch'а - это ну как критиковать машину по форме руля.
Хм. Ответ на это состоит из двух отдельных мыслей - учти.
1. Лично я привык отделять мух от котлет. То есть для меня "великолепная машина, но с неудачным рулем" - вполне разумная характеристика.
2.1 Некий человек сказал, что "бэт сайтов" не видит - причем в контексте довольно неграмотных попыток назвать плохие стороны дельфы.
2.2. Я назвал несколько "бэт сайтов" джавы - именно в контексте "хорошая вещь для своих задач, но имеет и недостатки".
2.3. Вы (мои оппоненты, извини, не хочется читать еще раз весь тред, чтобы найти поименно) обратили внимание на одну из деталей одного из названных мной недостатков.
2.4. Теперь ты говоришь, что я критикую джаву по этой детали - ты уверен, что это корректно? Я готов заявить, что если бы это был единственный недостаток джавы - она была бы абсолютно, немыслимо великолепным продуктом. Но ряд таких мелочей - то, что реально раздражает, суммарно являются существенным (для меня) недостатком.
2.5 Я понимаю точку зрения "я привык именно так и неудобным кажется все остальное".
