Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

тут просто небольшая путаница возникла:

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

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

Добавлено 29.04.11, 17:39
так вот конструктор -- метод, определенный в метаклассе, вызываемый через класс, т.е. диспетчеризация происходит по классу -- метаобъекту.

Добавлено 29.04.11, 17:41
а если бы при вызове конструктора, описанного в метаклассе создавались не объекты, а классы, тогда бы можно было говорить, что метаклассы порождают классы. но я себе не представляю, как бы это могло быть сделано в делфи.

Цитата korvin @ 29.04.11, 17:37

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

а, так это же метаметод метакласса! Так бы метасразу и сказал.

korvin, хватит путать Отличить метод класса от метода объекта можно по self, скрытому параметру. В методе класса он указывает на класс, а у объекта - на объект.
Поскольку в конструкторе он указывает на объект, то конструктор по этому признаку - метод объекта. По форме вызова он метод класса, поскольку есть неявная обвязка, собственно конструирование. Код я приводил.
Как в С++ конструктор может быть методом класса, если this там указывает на экземпляр - вот это и надо выяснить

Цитата D_KEY @ 29.04.11, 10:14

Цитата DesweR @ 29.04.11, 09:53

Цитата KILLER @ 29.04.11, 07:54

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

?

A* a;// = new A;
a->Foo();
a->Bar();

Тут нет экземпляра.

Ты не убегай Забыть написать можешь точно также и никто не поможет.

Цитата D_KEY @ 29.04.11, 10:14

А если в конструкторе базового есть вызов полиморфного метода? Не сможет ли он испортить еще несформированный объект?

Я уже говорил про такие варианты развития.

Цитата D_KEY @ 29.04.11, 10:14

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

Да как же не будет? Если фактически всё останется на своих местах - ссылочные переменные и значимые переменные.

Цитата D_KEY @ 29.04.11, 10:14

Нечто не может являтся "виртуальным" и "статическим" одновременно. Ты имел в виду методы класса? Это да, хорошо

Да, классовые методы, в С++ они емнип называются просто статическими методами (в Delphi есть ещё статические классовые методы, отличаются только тем что нет доступа к self и не могут быть виртуальными).

Цитата KILLER @ 29.04.11, 11:30

Если взять во внимание тот факт, что в С++ конструкторы/деструкторы - фактически создают/разушают объект

А что тогда делают операторы new/delete? и на каких участках они вызываются? До/после всех конструкторов/деструкторов у наследников или между ними?

Цитата DesweR @ 29.04.11, 18:35

Ты не убегай Забыть написать можешь точно также и никто не поможет.

Это ты убегаешь. Что бы увидеть тут ошибку, никуда - в свои или чужие исходники - лезть не надо. В отличие от.
К тому же ты писал о "созданном" объекте. Тут его нет.

Сообщение отредактировано: Adil - 29.04.11, 19:39

Цитата korvin @ 29.04.11, 14:38

Цитата D_KEY @ 29.04.11, 14:29

Из всяких умных книжек и статей. Метакласс - это класс класса, т.е. его экземпляром является класс.

но он при этом не порождает классы, он их описывает, объекты порождает конструктор. =)

Объекты - да. Кстати, вот в питоне любопытно сделано - конструктор объекта вызывается через __call__ метод метакласса(который в случае обычного класса соответствует оператору вызова, т.е. () )
Это соответствует синтаксису, поскольку создание объекта выглядит так: MyClass(параметры).

Добавлено 29.04.11, 19:51

Цитата korvin @ 29.04.11, 14:40

Цитата D_KEY @ 29.04.11, 14:38

В Delphi, как я понял, они являются методом объекта.

нет, методом объекта там является инициализатор

а инициализатор - это который constructor ?

Добавлено 29.04.11, 19:57

Цитата DesweR @ 29.04.11, 18:35

Цитата D_KEY @ 29.04.11, 10:14

Цитата DesweR @ 29.04.11, 09:53

Цитата KILLER @ 29.04.11, 07:54

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

?

A* a;// = new A;
a->Foo();
a->Bar();

Тут нет экземпляра.

Ты не убегай Забыть написать можешь точно также и никто не поможет.

Я не убегаю. Может. Но экземпляра тут нет и в помине.

Цитата

Цитата D_KEY @ 29.04.11, 10:14

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

Да как же не будет? Если фактически всё останется на своих местах - ссылочные переменные и значимые переменные.

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

Цитата

Цитата D_KEY @ 29.04.11, 10:14

Нечто не может являтся "виртуальным" и "статическим" одновременно. Ты имел в виду методы класса? Это да, хорошо

Да, классовые методы, в С++ они емнип называются просто статическими методами (в Delphi есть ещё статические классовые методы, отличаются только тем что нет доступа к self и не могут быть виртуальными).

В С++ вообще нет методов класса. Есть только статические методы.
Еще интересен подход scala(и вроде как Nemerle), когда вообще нет ни методов класса, ни статических методов, зато можно описывать объекты(а не классы, синглетоны, грубо говоря).
А когда Java-классы мапятся на классы scala просто создаются две сущности: одна для класса, вторая - объект-класс, содержащий статические методы.
Это сильно упрощает язык, без потери возможностей.

Добавлено 29.04.11, 20:00

Цитата DesweR @ 29.04.11, 18:35

А что тогда делают операторы new/delete? и на каких участках они вызываются? До/после всех конструкторов/деструкторов у наследников или между ними?

operator new и operator delete вызываются исключительно для выделения и освобождения памяти. Информацией об объектах они не обладают.
конструкция new MyType(параметры) сначала вызывает operator new для выделения памяти, затем вызывает указанный конструктор.

Цитата Romkin @ 29.04.11, 10:48

Скорее даже можно сказать, что с каждым языком они пытаются работать точно как с С++ И когда это не получается - начинают обсирать. "Если это выглядит иначе, чем в С++ - значит, это неверно. Аминь".

Ну ведь пользовались же Птолемеевой системой, и горя не знали. И была истина. И были блаженны в неведении, пока не пришёл Коперник. Истина оказалась иной.
С полгода назад ещё было показано, что Дельфи своей мощной объектной моделью заставляет игнорировать, вот просто не даёт никакой возможности реализовать, популярные далеко не только в C++ паттерны. Всё познаётся в сравнении, так что не нас надо жалеть. Вы имеет полное право продолжать наслаждаться борландской системой мира моделью ООП, всё усложняющейся и усложняющейся. В нашей модели мир проще и при этом точнее.

Цитата Romkin @ 29.04.11, 12:19

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

А инициализировать можно? Уже давно согласились, что ваши инициализации так же индивидуальны, как наше конструирование. И пусть вас не беспокоит двойная работа, раз вас устраивает такая цена за малый выигрышь. Но давайте не будем тогда уж передёргивать.

Цитата Flex Ferrum @ 29.04.11, 12:37

Ибо эти методы могут работать в условии нарушенного инварианта состояния объекта.

Уже проходили. Что такое инваринаты, они может быть и знают, но либо хорошо прикидываются, чтоб не отвечать на неудобные вопросы, либо они им не нужны, иначе откуда столько тупых проверок в ран-тайме в началах чуть не каждого метода.
Заодно, предупреждая очередное недоумение: с RAII та же картина - либо оно им не нужно, иначе не было б столько try/finally, либо бесполезно объяснять, что это такое, реализовать сам Дельфи не даст, как я понял. Вернее, даст, но... вот нужен ли тебе в качестве удобной обёртки вокруг простой CRITICAL_SECTION аж полиморфный guard с RTTI и метаклассом, создающийся и разрушающийся не одной сотней инструкций и лежащий в хипе? Это при том, что EnterCriticalSection() и LeaveCriticalSection() укладываются от силы в пару десятков, когда нет конкуренции. Ну, да, можно не классом, а рекордом или обджектом, только тогда автоматизации тоже не будет, и опять вернёмся к try/finally. Всё это тоже проходили.
Их вполне устраивает, когда никто ни за что не отвечает, ну это редко, или наоборот, один в ответе за всех. Монолит, блин. Понятие разделения ответственности между классами в иерархии ввиду отсутствия инвариантов в Дельфи не существует. Правда, о декомпозиции не помню, чем кончилось. Наверно я как раз тогда ушёл из темы, налоело читать по 30 страниц воды за неполный рабочий полудень. Так что умеют ли они её, не знаю. Единственно что - про модули знатно поговорили, тоже усиленно на иностранном языке слушали.

Цитата Romkin @ 29.04.11, 13:59

Ну вот я и говорил, что в С++ объекты - сборка из предков, которая делает вид что она единое целое

Та много раз. Каждый отвечает за своё - и это правильно. У каждого свои инварианты - и это правильно. Никто выше не ведает о том, что у него внизу и есть там что-то вообще - и это правильно. Это - разделение ответственности. Каждый слой ответственнен за свою задачу, за лично себя. Это - правильно, потому что в этом заключается суть декомпозиции. Когда все играют по правилам, сборка не делает вид, а является единым целым. У вас нет разделения ответственности, и при этом точно также от поведения каждого зависит логическая целостность "сборки" - и не надо тут про "один раз за нас написали, лежит в библиотеке", там не меньше предположений о том, что все будут играть по правилам, - зато в вашем монолите никто не сможет однозначно определить свою роль в этой целостности и свои полномочия и обязанности по поддержанию сборки в порядке. Так что тут мы даже ничем не платим, платите вы.

Цитата korvin @ 29.04.11, 17:37

тут просто небольшая путаница возникла:

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

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

Шедеврально! Не, в натуре, это на ithappens.

Цитата Qraizer @ 29.04.11, 21:58

Шедеврально! Не, в натуре, это на ithappens.

Что, ты опять ничего не понял?

Я так думаю, что он восхищен полетом мысли. Все эти метаклассы, метаметаклассы, метаметаметаклассы, метаметаметаметаклассы, метаметаметаметаметаклассы, ...

Цитата korvin @ 30.04.11, 05:01

Что, ты опять ничего не понял?

Та не. Причём тут. Просто шедеврально. Это надо как скороговорку выучить и на работе коллег пугать. А заказчикам ею внушать к себе уважение.

korvin, а что ты думаешь о подходе scala, где решили не усложнять мета-'ми систему типов? При этом "мощность" языка не пострадала, да и некоторые интересные концепции в языке присутствуют.

Цитата D_KEY @ 30.04.11, 08:11

korvin, а что ты думаешь о подходе scala, где решили не усложнять мета-'ми систему типов? При этом "мощность" языка не пострадала, да и некоторые интересные концепции в языке присутствуют.

ээ... scala в первую очередь ориентирован на функциональный подход, ООП там сбоку, постольку поскольку

Добавлено 30.04.11, 11:07

Цитата D_KEY @ 30.04.11, 08:11

не усложнять мета-'ми систему типов?

в чем сложность-то? метаобъектный протокол -- весьма правильный подход для ООП

Цитата korvin @ 30.04.11, 11:06

Цитата D_KEY @ 30.04.11, 08:11

korvin, а что ты думаешь о подходе scala, где решили не усложнять мета-'ми систему типов? При этом "мощность" языка не пострадала, да и некоторые интересные концепции в языке присутствуют.

ээ... scala в первую очередь ориентирован на функциональный подход, ООП там сбоку, постольку поскольку

scala нацелена на мультипарадигмальность, на тесную интеграцию разных подходов(не только функционального и ОО, там есть попытки реализации различных идей).
Даже алгебраические типы данных сделаны через специальный механизм так называемых case-классов

Цитата

Цитата D_KEY @ 30.04.11, 08:11

не усложнять мета-'ми систему типов?

в чем сложность-то? метаобъектный протокол -- весьма правильный подход для ООП

Что он дает на практике?

Сообщение отредактировано: D_KEY - 30.04.11, 11:44

Цитата Qraizer @ 29.04.11, 21:58

Вы имеет полное право продолжать наслаждаться борландской системой мира моделью ООП, всё усложняющейся и усложняющейся.

Как в кривом зеркале, ей богу. С высоты полёта (над обоими языками) дельфийская модель видится более развитой.

Цитата Qraizer @ 29.04.11, 21:58

В нашей модели мир проще и при этом точнее.

Органиченной, за что все и критикуют (и даже критики ООП).

Цитата Qraizer @ 29.04.11, 21:58

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

Опять кривое зеркало, давай более развернуто.

Цитата Flex Ferrum @ 29.04.11, 12:37

Понимаешь, в чём тонкость. Да, из за явного этапа инициализации ребёнок будет проинициализирован (в соответствии с перечисленными тобою правилами). Но! Формальная инициализированность экземпляра объекта не означает, что его состояние валидно. Валидным (с точки зрения объекта) его состояние будет только после отрабатывания его конструктора. И это неприятный факт ты обязан учитывать в тех виртуальных методах, которые вызываются из конструкторов предков. Ибо эти методы могут работать в условии нарушенного инварианта состояния объекта.

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

Цитата Qraizer @ 29.04.11, 21:58

Заодно, предупреждая очередное недоумение: с RAII та же картина - либо оно им не нужно, иначе не было б столько try/finally, либо бесполезно объяснять, что это такое, реализовать сам Дельфи не даст, как я понял. Вернее, даст, но... вот нужен ли тебе в качестве удобной обёртки вокруг простой CRITICAL_SECTION аж полиморфный guard с RTTI и метаклассом, создающийся и разрушающийся не одной сотней инструкций и лежащий в хипе? Это при том, что EnterCriticalSection() и LeaveCriticalSection() укладываются от силы в пару десятков, когда нет конкуренции. Ну, да, можно не классом, а рекордом или обджектом, только тогда автоматизации тоже не будет, и опять вернёмся к try/finally. Всё это тоже проходили.

А для реализации легковестного try/finally в С++ как будто не нужен "guard" из класса? Впрочем это тоже проходили.
P.S. А реализация RAII в Delphi гораздо проще, чем тебе кажется, нужен только интерфейсный объект.

Цитата Qraizer @ 29.04.11, 21:58

Их вполне устраивает, когда никто ни за что не отвечает, ну это редко, или наоборот, один в ответе за всех. Монолит, блин. Понятие разделения ответственности между классами в иерархии ввиду отсутствия инвариантов в Дельфи не существует. Правда, о декомпозиции не помню, чем кончилось. Наверно я как раз тогда ушёл из темы, налоело читать по 30 страниц воды за неполный рабочий полудень. Так что умеют ли они её, не знаю. Единственно что - про модули знатно поговорили, тоже усиленно на иностранном языке слушали.
...
У вас нет разделения ответственности, и при этом точно также от поведения каждого зависит логическая целостность "сборки" - и не надо тут про "один раз за нас написали, лежит в библиотеке", там не меньше предположений о том, что все будут играть по правилам, - зато в вашем монолите никто не сможет однозначно определить свою роль в этой целостности и свои полномочия и обязанности по поддержанию сборки в порядке. Так что тут мы даже ничем не платим, платите вы.

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

Сообщение отредактировано: DesweR - 30.04.11, 12:56

Цитата DesweR @ 30.04.11, 12:56

С высоты полёта (над обоими языками)

Во сне летаешь? Мы тут уже не раз убеждались в высоте твоего полета