OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 14 Ноябрь, 2019 23:16

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Среда, 25 Ноябрь, 2009 22:47 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Достаточно долгий период беспокоит меня данный вопрос.

По сравнению с действительно ядром в базовом Обероне, КП-шные средства (связанные процедуры и сопряжённые механизмы) кажутся (субъективно) менее фундаментальными. Лично я пока не отточил безупречного способа их вводить в учебном курсе.

Т.е. вопрос: сколько в них действительно "ядерного", а сколько - конкретно-исторически-сложившегося, что ещё должно быть перетрясено? (бесспорно, хорошо сложившегося, из опыта EthOS Шиперского и Оминк с ББ, но...).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Ноябрь, 2009 23:20 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Связанные процедуры придают объектам больший "вес" в системе. Если вместо них используются процедурные переменные, то записи становятся просто данными, а процедуры - просто алгоритмами. Это более сбаллансированная система, но она требует больших усилий как для анализа структуры проекта, так и для рутинной работы с ним:
- obj.method(obj, ...); - дублирование "obj" при вызове метода;
- более длинная инициализация экземпляра при создании, поскольку все методы надо присвоить ему вручную;
- наследование метода выглядит слишком низкоуровнево: сохраняем копию процедуры, ставим свою процедуру, своя должна вызывать сохранённую копию;
- возможность во время выполнения изменять связанную процедуру не только затрудняет понимание структуры программы, но и делает невозможным наследование метода в общем случае без введения специальных механизмов и соглашений;
- есть возможность переопределить часть методов объекта во время исполнения, не создавая при этом нового типа. Я так понимаю, что это наносит серьёзный удар по одному из важных принципов ООП, согласно которому именно иерархия типов создаёт смысловой костяк программы, её понятийный аппарат.

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


Последний раз редактировалось Александр Ильин Среда, 25 Ноябрь, 2009 23:25, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Ноябрь, 2009 23:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Это понятно.

Мой вопрос нужно читать не с угла сравнения с Обероном (это уже считаем "проеханным"), а... ну, я написал же: можно ли признать эту группу средств КП устоявшимися (объективно, "научно"), или это ещё фаза поиска?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 25 Ноябрь, 2009 23:50 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Что-то я не понял вот этого момента.
Александр Ильин писал(а):
- наследование метода выглядит слишком низкоуровнево: сохраняем копию процедуры, ставим свою процедуру, своя должна вызывать сохранённую копию;
Можно по-подробнее?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 01:10 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Valery Solovey писал(а):
Можно по-подробнее?
Код:
TYPE
Object = POINTER TO ObjectDesc;
Method = PROCEDURE (obj: Object);
ObjectDesc* = RECORD
   do*: Method; (* overridable (="virtual") method *)
END;

NewObject = POINTER TO NewObjectDesc; (* this object can be in a different module *)
NewObjectDesc* = RECORD (ObjectDesc)
   inheritedDo: Method; (* a saved copy of ObjectDesc.do *)
END;

PROCEDURE DefaultMethod (obj: Object); (* can't be called directly if not exported from the base module *)
BEGIN
   (* do something *)
END DefaultMethod;

PROCEDURE Init* (obj: Object); (* initialize a new Object instance *)
BEGIN
   obj.do := DefaultMethod; (* assign the default method implementation *)
END Init;

(* the following procedures can be in a different module along with the NewObject itself *)

PROCEDURE NewMethod (obj: Object);
BEGIN
   obj(NewObject).inheritedDo(obj); (* <- call the inherited method *)
   (* do something else *)
END NewMethod;

PROCEDURE InitNewObject* (obj: NewObject);
BEGIN
   Init (obj); (* here obj.do will be initialized to the unpublished DefaultMethod *)
   obj.inheritedDo := obj.do; (* <- remember the inherited method *)
   obj.do := NewMethod; (* <- set our new method handler *)
END InitNewObject;
Для сравнения - аналогичный код на КП:
Код:
TYPE
Object* = POINTER TO EXTENSIBLE RECORD
END;

NewObject = POINTER TO RECORD (Object)
END;

PROCEDURE (obj: Object) Do* (), NEW;
BEGIN
   (* do something *)
END Do;

PROCEDURE (obj: NewObject) Do ();
BEGIN
   obj.Do^(); (* <- call the inherited method *)
   (* do something else *)
END Do;
Ни явных инициализаций, ни запоминания прежнего метода при наследовании. Автоматическое создание VMT супротив ручного.


Последний раз редактировалось Александр Ильин Вторник, 08 Декабрь, 2009 21:27, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 01:21 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Кстати, если я правильно понимаю, то подход с процедурными переменными-полями всегда будет работать быстрее таблиц виртуальных методов (VMT). Или нет?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 02:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Ну, вроде бы, на одну косвенность меньше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 09:40 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3108
Откуда: Астрахань
Да вводите просто: тип данных это есть множество значений + множество операций. Операции представляются в КП вот так. А чтобы обозначить, что эти операции для конкретного типа данных, вот вам параметр.

Мне подход КП нравится гораздо больше, чем в С++ и прочих. В КП ЯВНО задается параметр this, что снимает у начинающих МНОГИЕ неясности. Особенно непонятно - ЗАЧЕМ какой-то невидимый параметр, да еще указатель (с которыми большинство работает плохо).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 10:01 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 530
Откуда: Москва
Вот что я не понял при чтении описания языка, так это упоминание супер вызовов:
"It is recommended to minimize the use of procedure types and super calls, since they are considered obsolete." (выделение моё)
Насколько я понимаю, это и есть супер-вызов:
Александр Ильин писал(а):
obj.Do^(); (* <- call the inherited method *)
Если это так, за что они впали в такую немилость?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 10:29 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2932
Откуда: г. Ярославль
Я на FreePascal несколько раз влетал на трудновыловимые ошибки с супервызовами - банально забывал поставить вызов в нужном месте. Человеческий фактор, думаю, и есть основная причина немилости :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 10:40 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Peter Almazov писал(а):
Насколько я понимаю, это и есть супер-вызов...Если это так, за что они впали в такую немилость?
Да, это именно он самый и есть.
А в немилость впал оттого, что композиция объектов предпочитается наследованию. Наследование достаточно допускать только на одну ступень: абстрактный объект и его реализация-наследник.
При необходимости наследование реализации легко делается через композицию.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 10:48 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Валерий Лаптев писал(а):
Мне подход КП нравится гораздо больше, чем в С++ и прочих. В КП ЯВНО задается параметр this, что снимает у начинающих МНОГИЕ неясности. Особенно непонятно - ЗАЧЕМ какой-то невидимый параметр, да еще указатель (с которыми большинство работает плохо).
Согласен! Сразу становится ясно, что такое метод на самом деле. Я долго не мог понять, что такое ООП из-за разных дельфийских наворотов. Например, в Дельфи внутри метода не только есть этот скрытый параметр Self (и вместе с ним особый тип procedure of object), но и все поля объекта находятся внутри метода в области прямой видимости, наравне с локальными переменными. Приходится вводить соглашения об именовании: префикс F для полей. Даже когда на 10й раз прочитаешь справку, всё равно остаётся впечатление, что там ещё может быть что-то скрытое, умолчательное. В Обероне всё сразу на виду, и по единообразным правилам.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 10:51 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8196
Откуда: Троицк, Москва
Иван Кузьмицкий писал(а):
банально забывал поставить вызов в нужном месте. Человеческий фактор, думаю, и есть основная причина немилости :)
Не совсем. Если человеческий фактор подскальзывается на банановой кожуре -- кто виноват? В принципе, под ноги же можно смотреть. Но и кожуру подмести тоже можно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 10:53 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Александр Ильин писал(а):
А в немилость впал оттого, что композиция объектов предпочитается наследованию. Наследование достаточно допускать только на одну ступень: абстрактный объект и его реализация-наследник.
При необходимости наследование реализации легко делается через композицию.
Дело даже не в одной ступени, а в том, что некоторые ради возможности использовать ресурсы класса предпочитают наследование вместо объявления объекта. "Относледовался и используй себе".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 11:02 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2932
Откуда: г. Ярославль
Еще по поводу супер-вызовов. В документе "What's New in Component Pascal?" (Docu\CP-New.odc) написано:

Цитата:
Abstract methods may only be bound to abstract types, and they may not be called via super calls.


Ну а поскольку абстрактные методы используются довольно широко, то использование супер-вызовов не является "хорошим" стилем :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 11:10 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3108
Откуда: Астрахань
Александр Ильин писал(а):
Peter Almazov писал(а):
Насколько я понимаю, это и есть супер-вызов...Если это так, за что они впали в такую немилость?
Да, это именно он самый и есть.
А в немилость впал оттого, что композиция объектов предпочитается наследованию. Наследование достаточно допускать только на одну ступень: абстрактный объект и его реализация-наследник.
При необходимости наследование реализации легко делается через композицию.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 12:20 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Супервызовы весьма удобны при реализации сериализации/десериализации.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 14:54 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Александр Ильин писал(а):
Например, в Дельфи внутри метода не только есть этот скрытый параметр Self (и вместе с ним особый тип procedure of object)

Про procedure of object
Это не какой-то особый тип из серии рюшечек, а очень хорошая и нужная вещь.
Два dword-а, один из которых есть адрес объекта, а второй адрес его метода (хотя порядок кажется обратный).
Смысл в том, что если разделить их по отдельности, то такие яйца получатся - мама не горюй.
Вот в C++ есть тип "метод класса", отделенный от объекта (а методы-то разные бывают, и виртуальные в т.ч.).
Вот там и происходит это "мама не горюй". НИЗЯ, оказывается, на языке, позиционирующем себя как специально созданный для создания пользовательских типов, воспроизвести этот тип, простой как топор.

А когда все это в одном типе - стыковка типа объекта и его метода производится на уровне компиляции, в тот момент, когда такой переменной делается присваивание. Все же действительно просто как топор становится.
Вот поэтому в QT появляется кобинация слотов/сигналов, а в додиезе - делегаты.
Никак пока в толк не возьму, отчего в КП нет такого полезного типа :(

P.S. Это ничего, что я в терминах "атомно-молекулярной теории" изъяснялся ??? :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 15:16 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4525
Откуда: Россия, Орёл
Galkov писал(а):
Никак пока в толк не возьму, отчего в КП нет такого полезного типа
В КП есть метаинформация. По-моему это оно самое.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 15:33 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Galkov писал(а):
Никак пока в толк не возьму, отчего в КП нет такого полезного типа :(
Потому что выгоды от него в КП кот наплакал, так как в КП "сообщения рулят", а в языках со сборщиком мусора он ещё и неявным якорем объекта будет. Что касается дотнета, то там делегаты -- это самостоятельные объекты, со всеми вытекающими последствиями лишней нагрузки на сборщик мусора на каждый чих.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 21 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB