OberonCore https://forum.oberoncore.ru/ |
|
Безымянные ABSTRACT, EXTENSIBLE, LIMITED https://forum.oberoncore.ru/viewtopic.php?f=29&t=6600 |
Страница 1 из 2 |
Автор: | adimetrius [ Среда, 22 Апрель, 2020 17:04 ] |
Заголовок сообщения: | Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Коллеги, я наткнулся на то, что Сообщение о языке и компилятор допускают использование атрибутов с безымянными типами записей, например следующее: VAR r: EXTENSIBLE RECORD ... END; p: POINTER TO ABSTRACT RECORD ... END; q: LIMITED RECORD ... END; Но, поскольку атрибуты относятся к расширению типов, а расширить безымянный тип невозможно - кмк, правильно было бы запретить атрибутирование безымянных типов. Скорее всего, атрибут при безымянном типе говорит об ошибке программиста: он что-то не то ожидает, что получит. Что скажете? |
Автор: | adimetrius [ Среда, 22 Апрель, 2020 21:50 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
И еще язык позволяет вот такое определение: PROCEDURE P (r: RECORD ... END); При этом процедуру P невозможно вызвать, поскольку НИЧЕГО не совместимо с типом параметра r. Тоже, кмк, было бы хорошо запретить. Что скажете? |
Автор: | Борис Рюмшин [ Среда, 22 Апрель, 2020 22:22 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Ну так как в обоих случаях такая деятельность смысла не имеет и никто так не делает, то это можно просто проигнорировать. Запретить может обойтись дороже для компилятора. Однако, если там всё просто получается, то можно и запретить. |
Автор: | Иван Денисов [ Четверг, 23 Апрель, 2020 06:57 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Да, много таких вещей разрешено. В Центре обсуждали такой вопрос. Помню Йозеф убедил всех, что усложнять компилятор не стоит. |
Автор: | Илья Ермаков [ Четверг, 23 Апрель, 2020 08:12 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Да, ни к чему специально это запрещать, усложняя компилятор. Это же технически в модель времени выполнения отображается, всё нормально - а, что это абсолютно бесполезно, не проблема ) |
Автор: | AlexBogy [ Среда, 28 Декабрь, 2022 21:45 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Задам свой вопрос в этой теме, чтобы не заводить новую. Прошу знатоков языка прояснить мне следующий вопрос: Почему для абстрактных записей запрещено создание экземпляра, а для наследника этой записи 1 в 1, то есть Код: TYPE a=ABSTRACT RECORD c:INTEGER; END; b=RECORD(a) END; создание экземпляра разрешено? В чем смысл такого запрета? |
Автор: | adimetrius [ Четверг, 29 Декабрь, 2022 00:41 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
AlexBogy писал(а): Задам свой вопрос в этой теме, чтобы не заводить новую. Прошу знатоков языка прояснить мне следующий вопрос: Почему для абстрактных записей запрещено создание экземпляра, а для наследника этой записи 1 в 1, то есть Код: TYPE a=ABSTRACT RECORD c:INTEGER; END; b=RECORD(a) END; создание экземпляра разрешено? В чем смысл такого запрета? Рискну самозванно назваться знатоком языка и ответить на ваш вопрос. В общем случае тип ABSTRACT недореализован, и потому, с т.зр. его автора, переменные этого типа бессмысленны, а с т.зр. языка - возможно и чреваты авариями. Поэтому создание таких переменных запрещено. Недореализован - т.е. с ним связаны абстрактные типовые процедуры PROCEDURE (VAR v: a) P, NEW, ABSTRACT, которые должен реализовать расширитель. Вы приводите частный случай, когда недореализованных процедур нет, и переменная абстрактного типа может быть безопасно создана. Но, с одной стороны, этот частный случай не имеет практической значимости, а с другой - обнаружение такого частного случая затратно. Поэтому компилятор его не обнаруживает, и не разрешает вам создать переменную любого абстрактного типа. |
Автор: | AlexBogy [ Четверг, 29 Декабрь, 2022 09:31 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Спасибо за ваш ответ. Вы увязываете тип записи ABSTRACT с наличием в нем процедуры, которая обязательно должна быть определена при реализации (в отличие от пустой процедуры EMPTY). Но эта абстрактная процедура должна быть реализована в наследнике, который уже не является абстрактной записью, значит, абстрактная процедура, по идее, может быть привязана к любому типу записи (с моей точки зрения). Вывод о том, что абстрактная запись недоделана и ее реализация через наследника - на страх и риск программиста - имеет место быть, но с моей точки зрения не совсем убедителен. Еще раз благодарю вас за ваш ответ. |
Автор: | Иван Денисов [ Четверг, 29 Декабрь, 2022 09:42 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Что-то вы не так поняли, Антона. ABSTRACT задумана так. Если она указана, нельзя создать экземпляр. Это ключевое слово было специально задумано для создания такого запрета. |
Автор: | AlexBogy [ Четверг, 29 Декабрь, 2022 09:48 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Иван Денисов писал(а): Что-то вы не так поняли, Антона. ABSTRACT задумана так. Если она указана, нельзя создать экземпляр. Это ключевое слово было специально задумано для создания такого запрета. Спасибо вам за поправку, я некорректно заменил недореализована на недоделана. Я понимаю, что ABSTRACT сделан так, как вы говорите. Я спрашивал, какой смысл в запрете на реализацию оригинального экземпляра, если его можно реализовать в наследнике без добавления своих полей и процедур? |
Автор: | Sergej Durmanov [ Четверг, 29 Декабрь, 2022 11:24 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Всё это происходит из-за того, что сначала в КП ввели EXTENSIBLE записи, а когда усовершенствовали объектную модель, добавив абстрактные записи (которые по совместительству и extensible), пришлось сохранять староет поведение для совместимости - расширяемые записи не обязаны иметь методы. Поэтому такое нарушение логики абстрактных записей в кп - методы необязательны, но при этом инстанцировать экземпляр абстрактного типа невозможно. |
Автор: | AlexBogy [ Четверг, 29 Декабрь, 2022 11:37 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Sergej Durmanov писал(а): Всё это происходит из-за того, что сначала в КП ввели EXTENSIBLE записи, а когда усовершенствовали объектную модель, добавив абстрактные записи (которые по совместительству и extensible), пришлось сохранять староет поведение для совместимости - расширяемые записи не обязаны иметь методы. Поэтому такое нарушение логики абстрактных записей в кп - методы необязательны, но при этом инстанцировать экземпляр абстрактного типа невозможно. Спасибо за ваш ответ. Если возможно, ответьте тогда на еще один вопрос - чем была вызвана необходимость введения в каркас абстрактных записей и абстрактных процедур? |
Автор: | adimetrius [ Четверг, 29 Декабрь, 2022 12:43 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Sergej Durmanov писал(а): Всё это происходит из-за того, что сначала в КП ввели EXTENSIBLE записи, а когда усовершенствовали объектную модель, добавив абстрактные записи (которые по совместительству и extensible), пришлось сохранять староет поведение для совместимости - расширяемые записи не обязаны иметь методы. Поэтому такое нарушение логики абстрактных записей в кп - методы необязательны, но при этом инстанцировать экземпляр абстрактного типа невозможно. Какая логика и в чем ее нарушение? |
Автор: | adimetrius [ Четверг, 29 Декабрь, 2022 12:48 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Иван, вы верно меня поняли: я написал, что переменные ABSTRACT с т.зр. его автора бессмысленны. |
Автор: | Иван Денисов [ Четверг, 29 Декабрь, 2022 12:51 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
AlexBogy писал(а): Sergej Durmanov писал(а): Всё это происходит из-за того, что сначала в КП ввели EXTENSIBLE записи, а когда усовершенствовали объектную модель, добавив абстрактные записи (которые по совместительству и extensible), пришлось сохранять староет поведение для совместимости - расширяемые записи не обязаны иметь методы. Поэтому такое нарушение логики абстрактных записей в кп - методы необязательны, но при этом инстанцировать экземпляр абстрактного типа невозможно. Спасибо за ваш ответ. Если возможно, ответьте тогда на еще один вопрос - чем была вызвана необходимость введения в каркас абстрактных записей и абстрактных процедур? Это создано для решения проблемы "хрупких базовых классов", это главная проблема ООП. И она решена в Компонентном Паскале введением контроля за расширениями с помощью ключевых слов ABSTRACT, EXTENSIBLE, LIMITED, и соответствующего им поведения компилятора. |
Автор: | AlexBogy [ Четверг, 29 Декабрь, 2022 13:06 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Stores.Store реализован как абстрактная запись, хотя там нет ни одной абстрактной процедуры, только пустые. При создании клиентских модулей очень редко пользуются абстрактными записями, поэтому их введение вряд ли оказало влияние на безопасность создаваемых приложений с точки зрения 'хрупкого базового класса'. С учетом того, что абстрактная процедура может быть только в абстрактной записи (лично мне тоже не очень понятно, почему именно в этих записях), то абстрактная запись больше связана с введением абстрактной процедуры, чем с другими соображениями (на мой взгляд). И в чем различие в безопасности или надежности приложения от создания экземпляра от абстрактной записи или ее наследника? |
Автор: | Иван Денисов [ Четверг, 29 Декабрь, 2022 13:17 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
AlexBogy писал(а): Stores.Store реализован как абстрактная запись, хотя там нет ни одной абстрактной процедуры, только пустые. Суть в том, что нельзя разместить в памяти экземпляр такого класса, разместить можно только расширение. Так как только оно имеет "с точки зрения автора" какой-то смысл. Ключевое слово ABSTRACT ясно говорит, чего делать не стоит, и среда явно это запрещает. AlexBogy писал(а): При создании клиентских модулей очень редко пользуются абстрактными записями, поэтому их введение вряд ли оказало влияние на безопасность создаваемых приложений с точки зрения 'хрупкого базового класса'. Так в этом и суть, что клиенты уже пользуются абстрактными записями, а свои абстрактные могут и не создавать. AlexBogy писал(а): И в чем различие в безопасности или надежности приложения от создания экземпляра от абстрактной записи или ее наследника? В более определённом рамками поведении системы для разработчика каркаса. Разработчик может прогнозировать, как именно будут использованы записи. Что наследование, к примеру, произойдет с обязательным определением того или иного метода, а также, что никто не сможет создать экземпляр класса от типа не унаследовав его. Между разработчиком каркаса и его пользователем более регламентированное общение получается. Более чётко определены правила, меньше непредсказуемых неприятных моментов. |
Автор: | AlexBogy [ Четверг, 29 Декабрь, 2022 13:58 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Спасибо вам за ваши пояснения, Иван. У меня к вам вопрос, как к уважаемому программисту-практику. В вашей практике встречалась необходимость в ваших модулях по каким-либо причинам использовать абстрактные типы записей (с абстрактными процедурами или без них) ? Я ничего не имею против абстрактных записей. Я прекрасно понимаю необходимость абстрактных процедур. У меня только один вопрос - с вашей точки зрения, какими причинами может быть вызван запрет на аллокацию экземпляра непосредственно абстрактной записи, а можно делать аллокацию только через наследника? |
Автор: | adimetrius [ Четверг, 29 Декабрь, 2022 14:20 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
Хоть и не ко мне напрямую вопрос, но позвольте от себя ответить. Я пользуюсь абстрактными типами. Сейчас в приложении, которое я делаю, порядка 30 модулей, в одном из них я определяю абстрактный тип (с типовыми процедурами), в другом - пользуюсь этим абстрактным типом и процедурами, в третьем и четвертом - расширяю и реализую процедуры. Условно можно так сказать: абстрактный тип Фигура в первом модуле; тип Холст, на который помещается Фигура - во втором, и конкретные разновидности Фигур в третьем и четвертом. А вот пример, когда в одном модуле - и абстрактный тип, и конкретные расширения. Во входном тексте определяется перечень модулей и прочих артефактов, входящих в Коробку. С Коробками предусмотрен ряд действий, каждое из которых по-своему параметризуется. Синтаксический анализатор разбирает входной текст-определение Коробки, преобразует его во внутриязыковое структурное представление. И затем передает его Действию. Действие - это абстрактный тип; на этом абстрактном уровне определено взаимодействие Анализатора и Действия. Тип Действие расширяется для каждого действия, которое предусмотрено, и сейчас их три или четыре. |
Автор: | Иван Денисов [ Четверг, 29 Декабрь, 2022 14:24 ] |
Заголовок сообщения: | Re: Безымянные ABSTRACT, EXTENSIBLE, LIMITED |
AlexBogy писал(а): У меня к вам вопрос, как к уважаемому программисту-практику. В вашей практике встречалась необходимость в ваших модулях по каким-либо причинам использовать абстрактные типы записей (с абстрактными процедурами или без них) ? Я ничего не имею против абстрактных записей. Я прекрасно понимаю необходимость абстрактных процедур. У меня только один вопрос - с вашей точки зрения, какими причинами может быть вызван запрет на аллокацию экземпляра непосредственно абстрактной записи, а можно делать аллокацию только через наследника? Да, часто использую, когда требуется один интерфейс и несколько реализаций под разные случаи. Тогда интерфейс как правило оформляется с ключевым словом ABSTRACT. Вот примерчик, из программы над которой планирую корпеть дальше в январе. Решатель для многоуровневых систем. Код: MODULE BioSolver;
IMPORT BioModels, BioVectors, Meta; TYPE Force* = PROCEDURE( m: BioModels.Model; act: BioModels.Unit; OUT f: BioVectors.Vector ); Solver* = POINTER TO ABSTRACT RECORD m*: BioModels.Model; (* модель *) f*: Force; (* сила *) END; Factory* = POINTER TO ABSTRACT RECORD END; VAR factory: Factory; PROCEDURE (d: Factory) New* (par: POINTER TO ARRAY OF REAL): Solver, NEW, ABSTRACT; PROCEDURE (s: Solver) Step*, NEW, ABSTRACT; PROCEDURE New* (par: POINTER TO ARRAY OF REAL): Solver; BEGIN IF factory # NIL THEN RETURN factory.New(par) ELSE RETURN NIL END END New; PROCEDURE SetFactory* (f: Factory); BEGIN factory := f END SetFactory; PROCEDURE Load* (solverModule: ARRAY OF CHAR): BOOLEAN; VAR item: Meta.Item; proc: RECORD (Meta.Value) Install: PROCEDURE END; ok: BOOLEAN; BEGIN Meta.LookupPath(solverModule + ".Install", item); IF item.Valid() & (item.obj = Meta.procObj) THEN item.GetVal(proc, ok); IF ok THEN proc.Install; RETURN TRUE END END; RETURN FALSE END Load; END BioSolver. |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |