OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 21:48

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




Начать новую тему Ответить на тему  [ Сообщений: 39 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Среда, 30 Ноябрь, 2016 18:06 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Вообще, одно из напрягающих мест КП - это когда определение целостной абстракции (тип данных, константы, операции - методы и просто процедуры) разорваны "географически".

Оминки, кстати, ещё поощрили это, введя соглашение о том, что сначала все константы, потом типы, потом переменные...

Но, возможно, хорошо было бы иметь возможность и с процедурами чередовать объявления?

Допустим, оставив требование однопроходности (т.е. используемая переменная, тип, должны быть до использующей процедуры).

Засовывать методы в RECORD ... END в стиле Active Oberon считаю ненужным модничаньем.

А вот просто иметь возможность держать полное определение абстракции одним блоком - хорошо бы.

(Конечно, семантический редактор снял бы это противоречие влёгкую :) Но мы пока живём с текстовыми исходниками...)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Ноябрь, 2016 18:52 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
А при чём тут Ominc, если так было ещё в Паскале, за что ему попадало от Брайана Кернигана в статье о нелюбви к Паскалю?
Лично мне нравится такой порядок и я его придерживаюсь в любом языке, порядка так, что-ли, больше, но с точки зрения компромисса с другими людьми тоже посещали мысли о целесообразности запрета смешивать объявления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Ноябрь, 2016 19:13 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Не-не, я про Оминк упомянул то, что они в ББ в Соглашениях об оформлении кода не рекомендовали даже CONST-TYPE-VAR перемешивать.
Ну, например, разумно объявлять константы перечислений рядом с типом или переменной, для которой они заводятся.
А у них оно всё одной секцией CONST.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Ноябрь, 2016 19:43 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
То есть, в КП это возможно, но не рекомендуется? Просто в Паскале такой возможности вообще не было.
Нет её и в Обероне:
Код:
DeclarationSequence = [CONST {ConstDeclaration ";"}]
[TYPE {TypeDeclaration ";"}]
[VAR {VariableDeclaration ";"}]
{ProcedureDeclaration ";"}.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Ноябрь, 2016 19:48 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
А вот в Обероне 90-го такая возможность была, я не знал:
Код:
DeclarationSequence  =  {
 CONST {ConstantDeclaration ";"} |
 TYPE {TypeDeclaration ";"} |
 VAR {VariableDeclaration ";"}
}
{ProcedureDeclaration ";" | ForwardDeclaration ";"}


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

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
А как по мне, так порядок константы-типы-переменные-процедуры надо оставить. Это часть структуры. А структура облегчает контроль. Это методически верно.


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

Зарегистрирован: Вторник, 28 Август, 2007 00:55
Сообщения: 520
Откуда: Украина, Днепропетровская обл.
prospero78 писал(а):
А как по мне, так порядок константы-типы-переменные-процедуры надо оставить.
Т.е. чтобы нельзя было объявлять константы, вычисляемые из размера типов?

Код:
TYPE
  Rec = RECORD a, b: REAL END;
CONST
  RecSize2 = 2*SIZE(Rec);

Это в Дельфи можно объявлять типы-диапазоны на основе констант, в Обероне же более логичен такой порядок: типы-константы-переменные-процедуры.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 30 Ноябрь, 2016 22:50 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Oleg N. Cher писал(а):
Это в Дельфи можно объявлять типы-диапазоны на основе констант, в Обероне же более логичен такой порядок: типы-константы-переменные-процедуры.
Код:
CONST MaxNum = 15;
TYPE Elements: ARRAY MaxNum OF INTEGER;


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

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Делал я такое. И обсуждали когда-то, только найти не получилось.
Программы удобнее и понятнее получаются, но больше ни у кого не компилируются :( .


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Декабрь, 2016 07:30 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
В Активном Обероне произвольный порядок секций, и это бывает полезно, да.
Хотя для записей и объектов это не так уж актуально - методы описываются внути тела записи/объекта.
Так же я надеюсь, что допилят экспорт типов и констант из записей и объектов. И тогда вообще начнется совсем другая жизнь. Ибо порядок секций вообще будет играть незначительную роль


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 01 Декабрь, 2016 08:30 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1428
Илья Ермаков писал(а):
А вот просто иметь возможность держать полное определение абстракции одним блоком - хорошо бы.

Особенно очевидным это становится, если посмотреть на WinApi.


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

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
К вопросу о невозможности вычисления констант))

Код:
   (* операторы *)
    _опПлюс* = _lexWHILE + 1;
    _опМинус* = _опПлюс + 1;
    _опУмнож* = _опМинус + 1;
    _опДел* = _опУмнож + 1;
    _опИнверс* = _опДел + 1;
    _опКомерцИ* = _опИнверс + 1;
    _опЗпт* = _опКомерцИ + 1;
    _опТчкЗпт* = _опЗпт + 1;
    _опВерт* = _опТчкЗпт + 1;
    _lexLRound* = _опВерт + 1;


Что касается вычисления констант из размера типов, то здесь, имхо, методически не верный подход. Это КОНСТАНТЫ))) И всё-таки, их можно вычислить, если сначала описать тип, а только затем такой модуль импортировать в модуль констант. Самый грамотный вариант -- определить размер типа через соответствующий тип, и получать как поле "только на чтение".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 04:16 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 717
Откуда: Барнаул
prospero78 писал(а):
Самый грамотный вариант -- определить размер типа через соответствующий тип, и получать как поле "только на чтение".

Самый грамотный вариант - воспользоваться чем-товроде sizeof( mytype )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 11:59 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Цитата:
Самый грамотный вариант - воспользоваться чем-то вроде sizeof( mytype )

Кемет, видимо, ты не заметил. Я великодушно ещё раз приведу своё мнение по поводу констант.
Методически не верно определять КОНСТАНТЫ через ВЫЧИСЛЕНИЯ))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 13:21 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 13:40 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Илья, я же не утверждаю "Запретить и не пущать". Более того, даже если бы я такое написал, правило оно на то и существует, чтобы его нарушать))
Я высказал своё мнение, только по методике работы с константами, а не практической рализации теоретических методов)))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 14:44 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
prospero78 писал(а):
Методически не верно определять КОНСТАНТЫ через ВЫЧИСЛЕНИЯ))

Какой из следующих вариантов методически верен?
Код:
CONST
   SecondsInMinute = 60;
   MinutesInHour = 60;
   HoursInDay = 24;
   SecondsInHour = SecondsInMinute * MinutesInHour;
   SecondsInDay = SecondsInHour * HoursInDay;
Код:
CONST
   SecondsInMinute = 60;
   MinutesInHour = 60;
   HoursInDay = 24;
   SecondsInHour = 3600;
   SecondsInDay = 86200;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 15:01 
Аватара пользователя

Зарегистрирован: Воскресенье, 12 Апрель, 2015 18:12
Сообщения: 1134
Откуда: СССР v2.0 rc 1
Методически верны оба. Практически удобнее первый, хотя он и вычисляется, но вычисляемые константы являются производными от невычисляемых констант. Поле динамических состояний множества констант равно нулю. В рамках предложенного мною методического предположения))


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 15:44 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
prospero78 писал(а):
Методически верны оба. Практически удобнее первый, хотя он и вычисляется, но вычисляемые константы являются производными от невычисляемых констант. Поле динамических состояний множества констант равно нулю. В рамках предложенного мною методического предположения))
Во втором коде одна из констант содержит такую ошибку, которая невозможна в первом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Декабрь, 2016 15:48 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1447
Откуда: Киев
Код:
CONST
   SecondsInMinute = 60;
   MinutesInHour = 60;
   HoursInDay = 24;
   SecondsInHour = SecondsInMinute * MinutesInHour;
   SecondsInDay = SecondsInMinute * HoursInDay;

Вообще невозможна?


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

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


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

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


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

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