OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Понедельник, 18 Ноябрь, 2019 06:07

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




Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу 1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Среда, 02 Февраль, 2011 18:27 
Модератор
Аватара пользователя

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

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

Допускаются выступления двух характеров:

1) Конкретные примеры задач и кода (видимо, преимущественно из системного программирования), в которых, по мнению автора сообщения, имеются проблемы с конструкциями классического структурного программирования, с их обсуждением.

2) Обобщающие и теоретические сообщения, к авторам которых предъявляется обязательное требование - компетентность в области теории и методов программирования не ниже, чем на уровне 70-х, задаваемом работами Дейкстры "Дисциплина программирования" (формализация свойств программных конструкций и доказательное программирование), Гриса "Наука программирования" (учебник по методам Дейкстры), Вирта "Систематическое программирование" (нисходящее проектирование алгоритмов методом пошаговой детализации и уточнения и т.п.).
Специальное пояснение: не следует путать "Дисциплину программирования" с работами Дейкстры и др. по структурному программированию. Структурное программирование - это "эмпирика", и как раз оно является предметом дискуссионного обсуждения в данной ветке. Содержание "Дисциплины программирования" - метод логического рассуждения об алгоритмах, и он принимается для целей данной ветки за недискутируемый фундамент.


Сообщения, не соответствующие названному формату обсуждения, будут удаляться.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 18:28 
Модератор
Аватара пользователя

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

"Обобщённый цикл", заметка Петра Алмазова и обсуждение
"Конструкция AND THEN"
"Теория двумерного структурного программирования" - анализ и построения из опыта ДРАКОНа
"Что сказал Дейкстра в конце жизни" - библиографические выписки В.Д. Паронджанова
Форум "Структурные редакторы" - Сергей Прохоренко также анализирует данную проблематику и проектирует решения для своего редактора
"Рыжий vs Дейкстра" - критика структурного программирования "от Рыжего"


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 18:28 
Модератор
Аватара пользователя

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

Цитата:
Есть случаи, когда наиболее адекватная и вполне аккуратная структура программы потребовала бы для своей непосредственной текстовой записи goto с правилами "переход только ниже по тексту" и "входить внутрь цикла нельзя". Т.е. соответсвие дагу (в безциклическом случае) или сводимому графу (в циклическом случае). Вместо линейно-блочных графов в случае жёсткого "структурного". Графически это выражается без проблем, в тексте - проблемы...

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

От наличия goto в текущих условиях может быть только один вред. Хотя... Шут знает. Я знаю ряд людей, которые принципиально не используют break и continue (в Дельфи), гордятся "структурным программированием", но при этом клепают вместо break булевские переменные, а о правильном построении циклов не имеют ни малейшего представления.


Цитата:
Моё мнение - современники Дейкстры были правы в максиме "долой GOTO".
Это сейчас хорошо эдак порассуждать "а вот тут, а вот так, а вот особые случаи, а вот ничего страшного нет".

Но задумайтесь над разницей в ситуации - когда в те годы большинство программистов вообще кроме таких переходов ничего не использовало.
И перейти на новый уровень развития можно было только "на отрицании". Чтобы возвести стену между поколениями программистов и подходов - и чтобы старый неуправляемый стиль не "всасывался с молоком", сразу отрабатывался жёстким "иммунитетом". Иначе так бы и писали...

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

Это нормальный и оптимальный путь НТР.

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


Цитата:
Сергей Прохоренко писал(а):
1) А для чего это может понадобиться? Реально встречаются такие ситуации? Если да, то для такой ситуации, с учетом ее особенностей, вполне можно сделать многоветочную уравляющую конструкцию типа switch без break в Си - в духе структурной парадигмы программирования. Можно даже использовать в заголовке конструкции ключевое слово goto. :D

2) Если наложить столь жесткие ограничения, то такой goto легко заменяется на невложенные IFы:

k := z;
IF k > 0 THEN
...
END;
IF k > 1 THEN
...
END;
IF k > 2 THEN
...
END;


Возможно.

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

Возьмите самый обычный ациклический алгоритм. Пусть его граф - ДАГ (= ориентированный ациклический, как граф импорта). Что в этом ДАГе плохого или неясного, с точки зрения восприятия программы или понимания её свойств? Почему всё-таки необходимо наворачивать дублирование, дополнительные переменные и проч., только лишь чтобы сделать алгоритм удобным для записи линейно-структурным текстом?

Это размышления "по самому общему счёту".
Разумеется, для дня сегодняшнего и его реалий я могу найти кучу аргументов за то, чтобы укладываться в классические структурные конструкции.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 21:54 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Попробую сюда добавить то, что хотел высказать ранее, но не успел. Контекст "того топика" полностью убрать не получается – приношу извинения. Надеюсь, затруднит прочтение не сильно.

Мне представляется, что статья Каратаева, является продуктом не сторонника GOTO, а противником возведения принципов структурного программирования в религию.
По-моему, это там прямо и указано.
В этом смысле, так я согласен с Автором. Не являясь в то же время фанатиком этого оператора.

Да, мы признаем большую важность плюсов привносимым изгнанием GOTO из ЯВУ. И мы понимаем, на какие жертвы нам приходится идти ради этих плюсов.
Это потеря эффективности. А в некоторых случаях – и понимаемости кода.
Такая точка зрения мне представляется правильной.

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

Ровно так же, абсолютно неправы те, кто считает, что каждый язык обязан иметь GOTO. Дулю им с маком. Сторонники первого подхода имеют на него полное право, при своих условиях.

Продолжим аналогию с инструментами: есть шлямбур и молоток – ими можно как порезаться, так и расплющить пальцы. И есть электродрель... Или даже какая-то супер-пуперель. Которая великолепно и безопасно изготавливает отверстия. Даже пусть и мусор за собой подбирает. Одна незадача – точнее 5 мм отверстие не изготовишь. А так – ну все прекрасно.
Надо ли рвать рубаху на груди, заявляя, что использование шлямбура является мракобесием ???
Моя точка зрения – НЕТ. Не отрицая важности безопасной работы, можно утверждать о существовании серьезного круга задач, где точность нужна в 0.1 мм.

Правильная, как мне кажется, точка зрения: направить свои усилия вместо холивара, на совершенствование супер-пуперели, чтобы работала точнее шлямбура.
Не факт, что интеллектуальные усилия, потраченные на холивары про GOTO в мировом масштабе – окажутся меньше необходимых для "совершенствоания".
И есть интересное наблюдение: считающие, что "с GOTO абсолютно все ясно", про качество компиляции даже и слышать не хотят.
Ну вот, с ними я серьезно не согласен.


Обобщение: практически любое Знание является условным. Даже закон сохранения энергии.
Для изгнания GOTO – условие признания привносимых изгнанием минусов.
Абсолютизация любого знания не менее вредна, чем его отсутствие. Потому что получается религия. Практически с той же терминологий.
А что вредней: фанатизм ЗА GOTO, или фанатизм структурного программирования - не скажу даже. Любой не подарок.

Самую малость по конкретике в топике (последнем) про GOTO.
1) Не согласен, что если "хочешь GOTO – используй ассемблер". Никто не хочет GOTO, но все хотят результатов им достигаемых. Так вот я хочу, чтобы ЯВУ без GOTO давал результаты не хуже, чем с ним.

2) И место ему не только в ассемблере. Например, C считается "платформенно независимым ассемблером".

3) Предположим, что Геннадий занимается генерацией кодов по ДРАКОН-схеме. Тогда он имеет полное право использовать как GOTO, так и другие, скажем так - фокусы.
Мое мнение: тот, кто скажет, что он только по этой причине не умеет программировать – есть человек необразованный. Не понимающий банального факта – что вся надежность ручного кодирования ему до лампочки. И, следовательно, плюсов от "изгнания GOTO" не остается, а минусы результирующему коду не нужны.

4) Ну предположим, я пишу компилятор компиляторов типа CocoR. Или вместо, по причине его неадекватности. Спрашивается, за каким лядом мне нужны преимущества изгнания GOTO в результирующем коде ???.
И чего делать, если семантики даны в Оберон-кодах. Вопрос для размышления. Над самым лучшим решением, а не над первым работающим.

В общем, как-то так: говорить о факте изгнания GOTO – преждевременно, пока его работу не заменили компиляторы. Это - выдавать желаемое (в т.ч. и мною), за действительное.

Вот Илья Евгеньевич пишет, что типа "а куда Дейкстре было деваться при том бедламе".
Да соглашусь просто. И добавлю, что прошло уже много десятилетий без видимых изменений в реализации "автоматного while-switch-case". Не одно, а МНОГО.
Что свидетельствует о том, что ВСЕ разработчики (компиляторов) его, адекватный на то время, компромисс - используют как решение проблемы с религиозным фанатизмом.
И не факт, что именно этого Дейкстра и хотел. Мое личное мнение: умный человек Дейкстра не мог хотеть религиозного фанатизма. Именно потому, что умный.

Резюме: что тут "абсолютно все ясно", и "наши победили" – не очень соответствует действительности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 22:47 

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 530
Откуда: Москва
Надо четко различать 2 случая: код, предназначенный для чтения человеком и код для процессора.
Второй случай не имеет смысла обсуждать вообще. Любой IF, ВЫБОР, ЦИКЛ - это набор GOTO на нижнем уровне, если только мы не имеем с экзотической архитектурой. И на эти GOTO никто не покушался и покушаться не собирается.
В случае кода, которой генерирует Дракон Геннадия Тышова, это как раз тот самый второй случай. Код просто не предназначен для человека.

А вот первый случай обсудить интересно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 22:53 
Модератор
Аватара пользователя

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

Предисловие.
Ничего принципиально нового, всё это нам известно, просто взглянем, как следует :)
Из структурного программирования мы привыкли к древовидной декомпозиции действий.
Например, есть действие A. Очень крупное.
Его определение даётся в терминах нескольких действий помельче: A = A1 A2 A3.
Далее A1, A2, A3 определяются аналогичным образом.

Есть и другой способ декомпозиции действий, кроме такого древовидного. Назовём его списочным. (Лисперам он сразу напомнит CAR-CDR :) ).
При определении большого действия A мы сначала указываем действия на мелком уровне детализации, а потом некое крупное, которое является продолжением этих мелких:
A = o1 o2 A1.
A1 = o3 o4 A2.
A2 = ...
Часто начинающие пытаются составлять алгоритмы именно в таком стиле, за что "бывают биты" - ведь для императивного языка такие вызовы связаны с углублением в стек (а потенциально и с рекурсией, если циклическое продолжение).
Однако, объективно, такой стиль декомпозиции действий для многих задач вполне естественный. Мы привыкли к такой декомпозиции из БНФ-грамматик. Антони Хоар в своей книге "Последовательные взаимодействующие процессы" вводит формализм для описания процессов также именно с таким стилем декомпозиции.

Ну и, наконец, для функционального программирования такой стиль вполне привычен. Например, конечные автоматы программируются часто именно так. Почему нет проблем? Потому что функциональные компиляторы понимают, что вызов концевой, и оптимизируют его просто до перехода на следующую процедуру (если есть параметры, то с замещением на стеке).
----

Собственно, вот вам и "культурный GOTO", хоть для конечных автоматов, хоть для какой-то сложной структуры процессов. Это - концевой вызов процедуры, который бы распознавался компилятором - и это распознавание бы гарантировалось.

Однако, следуя идеологии Оберона "всё явно", стоит ввести отдельный оператор, в пару к RETURN.
Назвать, например, CONTINUE.
CONTINUE Proc(params) - прекращает выполнение текущей процедуры, снимая её кадр со стека, и вызывает Proc(params).
Если наша процедура является функцией, то Proc тоже должна быть функцией соответствующего типа.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 02 Февраль, 2011 22:57 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9155
Откуда: Россия, Орёл
Остаётся только добавить, что это средство будет наиболее полезно на уровне вложенных процедур. Если все данные объявлены в объемлющей процедуре, а вложенные, CONTINUE-мые, не имеют ни параметров, ни своих переменных, то компилятор должен вообще генерировать чистые безусловные переходы без всяких других лишних инструкций.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 00:14 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Идея прекрасная. Она мне напоминает действие оператора escape(имя исключения) в механизме исключений в PureBuilder. Там аварийную процедуру/функцию тоже безжалостно уничтожают 8) , и от нее не остается даже следов (и никаких проблем с "восстановлением после сбоя"! :D ).

Только процедуры без параметров, т.е. с глобальными переменными, мне совсем не нравятся. :( А также не очень нравится слово CONTINUE. Оно сильно ассоциируется с циклами и неполно отражает смысл произошедшего события (для уничтоженной процедуры уже ничто не продолжается). На ум приходит слово reincarnate.

Остались еще вопросы. Процедура А вызвала процедуру Б. Та, в свою очередь, отдала управление процедуре В и бесследно исчезла. Что произошло с процедурой А? Она ждет возврата управления теперь из процедуры В (которая в этом случае должна иметь те же параметры, что и почившая Б), или же она тоже приказала долго жить? Передала ли перед смертью процедура Б процедуре В свою бессмертную душу (т.е., значения входных параметров и локальных переменных), и каким образом? Или значения параметров были снова взяты из процедуры А?

Наверное, отвечая на эти вопросы, стоило бы оттолкнуться от потенциального применения этой конструкции. Например, процедура - это автомат в каком-то определенном состоянии. Какое поведение разрабатываемой конструкции было бы естественно для такого автомата?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 00:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9155
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Только процедуры без параметров, т.е. с глобальными переменными, мне совсем не нравятся. :(


Так не глобальными.. А локальными. В некоторой объемлющей процедуре. А в ней блоки действий сделаны как вложенные процедуры. Т.е. декомпозиция на процедуры без параметров служит уже только для формирования структуры передачи управления (конечный автомат или просто не совсем стандартно-структурная логика, как с ANDTHEN).

Цитата:
А также не очень нравится слово CONTINUE. Оно сильно ассоциируется с циклами и неполно отражает смысл произошедшего события (для уничтоженной процедуры уже ничто не продолжается). На ум приходит слово reincarnate.


Мне тоже не особо нравится, но лучше что-то короткое.

Цитата:
Остались еще вопросы. Процедура А вызвала процедуру Б. Та, в свою очередь, отдала управление процедуре В и бесследно исчезла. Что произошло с процедурой А? Она ждет возврата управления теперь из процедуры В (которая в этом случае должна иметь те же параметры, что и почившая Б), или же она тоже приказала долго жить? Передала ли перед смертью процедура Б процедуре В свою бессмертную душу (т.е., значения входных параметров и локальных переменных), и каким образом? Или значения параметров были снова взяты из процедуры А?


Нет, никто никого не ждёт. Семантика полностью такая, как если Вы напишете:
PROCEDURE А; BEGIN .... Б END A;
PROCEDURE Б; BEGIN ... В END Б;

Только кадр вызывающей процедуры бесседно исчезает. После того, как все процедуры отпередают друг другу эстафету, произойдёт возврат в процедуру, которая вызвала A.

К переменным каким-то общим имеется доступ только в том случае, если через CONTINUE друг другу делегируют вложенные процедуры той процедуры, которая держит эти переменные общие. Разумеется, делегировать можно только процедуре равного уровня вложенности или более высокого. Своим вложенным процедурам делегировать нельзя.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 00:42 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Илья Ермаков писал(а):
Если наша процедура является функцией, то Proc тоже должна быть функцией соответствующего типа.
А процедуры-функции можно лишить концевых вызовов. Не велика потеря.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 00:44 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Идея нуждается в проработке. Лучше с картинками. :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 00:57 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9155
Откуда: Россия, Орёл
Сергей Губанов писал(а):
Илья Ермаков писал(а):
Если наша процедура является функцией, то Proc тоже должна быть функцией соответствующего типа.
А процедуры-функции можно лишить концевых вызовов. Не велика потеря.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 05:55 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Илья Ермаков писал(а):
...
Предисловие.
Ничего принципиально нового, всё это нам известно, просто взглянем, как следует :)
Из структурного программирования мы привыкли к древовидной декомпозиции действий.
Например, есть действие A. Очень крупное.
Его определение даётся в терминах нескольких действий помельче: A = A1 A2 A3.
Далее A1, A2, A3 определяются аналогичным образом.

Есть и другой способ декомпозиции действий, кроме такого древовидного. Назовём его списочным. (Лисперам он сразу напомнит CAR-CDR :) ).
При определении большого действия A мы сначала указываем действия на мелком уровне детализации, а потом некое крупное, которое является продолжением этих мелких:
A = o1 o2 A1.
A1 = o3 o4 A2.
A2 = ...
...
Сергей Прохоренко писал(а):
Идея нуждается в проработке. Лучше с картинками. :D
Не подойдут ли для иллюстрации этих способов картинки в этой выдержке (понимая "продолжение" как "следование")? Можно полагать, что:
    * Схемы на Рис. 105, 106 (чистые концепции) соответствуют первому способу - вся схема есть крупное действие и делится тоже на крупные (менее) действия-вставки.
    * Схема на Рис.107 уже не концепция в чистом виде - т.к. имеются операторы, не являющиеся вставками-процедурами (здесь - вершины-действия) - т.е. это частично конкретизированный визуал. И она, видимо, соответствует второму способу.
А как обращаться с параметрами и прочими затрагиваемыми величинами - м.б. показать в формах, описанных здесь...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 12:48 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 15:41 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Илья Ермаков писал(а):
Сергей Губанов писал(а):
Илья Ермаков писал(а):
Если наша процедура является функцией, то Proc тоже должна быть функцией соответствующего типа.
А процедуры-функции можно лишить концевых вызовов. Не велика потеря.


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


А если все вызываемые процедуры/функции будут одного типа (и, соответственно, с одинаковым набором параметров и типом возвращаемого значения), а передача параметров будет происходить неявно и автоматически - по эстафете? Чем тогда плохи параметры? А хороши они тем, что все переменные будут строго локальными.

А локальные процедуры - это не очень хорошо.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 15:45 
Аватара пользователя

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


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9155
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
А локальные процедуры - это не очень хорошо.


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

Если не дадите программисту локальных процедур, то он так и оставит. А дадите - появится возможность кое-где выполнить дополнительную декомпозицию действий, в тех процедурах, где делить и изолировать контекст уже дальше некуда.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 16:00 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Дробление и вложенность - разные вещи. Мелкие процедуры не обязаны быть вложенными. А программисту надо дать не механизм "вкладывания" процедур (со всякими заморочками относительно видимости имен), а механизм необременительного выделения части кода в обособленную процедуру. А чтобы не запутаться в море мелких процедур, их надо сгруппировать в модули (а модули в подсистемы и т.д.).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 16:41 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Сергей Прохоренко писал(а):
Дробление и вложенность - разные вещи...
Ну да... в "режиме" существует же "вертикальное" и "горизонтальное" разделение доступа (к подрежимным объектам)... в основе которого-то и лежит разделение объёма "предметки" и по иерархии, и на одном уровне иерархии... т.е. и то и другое (в смысле механизмы и вкладывания, и группировки) для сложных проектов нужно...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 18:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9155
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Дробление и вложенность - разные вещи. Мелкие процедуры не обязаны быть вложенными.

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

Я ж и говорю: без вложенных процедур Вы остановитесь на некотором уровне, дальше которого рвать связанность по переменным уже невыгодно. А с вложенными поделите чуть глубже. Те же вложенные функции для условий циклов часто объявляются.


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

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


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

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


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

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