Добавить методы в О7/13

[ilovb]

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

Я раньше тоже так думал. До тех пор пока не начал пользоваться. На практике же ситуация другая. HALT вылетает сразу. Причина банальна. Когда мы добавляем новое сообщение, то 100% мы его тестируем, т.е. делаем хотя бы 1 прогон с этим новым сообщением.
Если разраб свой код вообще не запускает и вываливает в продакшин, то да... беда.

[vlad]

А чем конкретно в данном случае ошибка компиляции лучше?

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

Предлагаю увеличить масштаб. У тебя мегапроект. Ты нашел все 100 мест (я не преувеличиваю - 100), где этот енум фигурирует в CASE и поправил эти места. Что дальше?
- Прогнать ты все эти места физически не можешь. Даже профессиональный QA не может. Автоматические тесты со 100% покрытием для старых мегапроектов (все мегапроекты - старые) - это из области космической фантастики.
- Таки одно место из этих 100 ты не поправил (мышка дрогнула).
- Ты искал только в мегапроекте, а есть еще несколько проектов поменьше (и тоже старых, их пересобирают раз в год и никто не хочет с ними иметь дело), которые тоже используют этот енум. На руках у тебя не вся codebase (например потому, что тебе не нужны все поддерживаемые платформы), поэтому все 200 мест ты не нашел. А если и нашел, то все равно ничего собирать, запускать и проверять не будешь.

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

[ilovb]

Я не спорю, что ошибка времени компиляции лучше. Лично мне не очень понятно, что планируется получить в итоге.
При изменении языка можно руководствоваться разными соображениями:
1. Джаст фо лулз.
2. Сделать качественно на чужом опыте.
3. Сделать качественно, но не так как у других.

Если 1 пункт, то и говорить не о чем (что хочешь, то и воротишь)
Если 2 пункт, то можно сделать 1:1 как в O2, к примеру. Тут тоже не о чем особо говорить (варианта всего 2... либо делать, либо нет)
А вот третий пункт требует сжигания калорий в большом количестве. Закон сохранения энергии никто не отменял. Качественный результат получается только при значительных затратах энергии.
Кто-то эту энергию должен потратить. Либо другой чувак (пункт 2), либо сам (пункт 3).
Энергию, конечно, можно разными путями тратить. Можно усиленно думать и методично добиваться результата, а можно ткнуть пальцем в небо и долго-долго потом наступать на грабли, модифицировать и отлаживать сие.

Предлагаю увеличить масштаб. У тебя мегапроект. Ты нашел все 100 мест (я не преувеличиваю - 100), где этот енум фигурирует в CASE и поправил эти места. Что дальше?

Мне очень сложно себе представить, чтобы у объекта было 100 методов.
И кроме того, даже эти сто методов, по идее, должны быть в одном модуле, если мы на Обероне пишем.

Я в общем то не против ООП. Даже всеми руками за. Вопрос лишь в том, как это сделать правильно. А это как, имхо, должно вырасти из весомых причин.
Можно сделать как в O2, но чем это будет отличаться от O2? 

[ilovb]

Еще добавлю:
Если отталкиваться от реальных конкретных задач, то в данном твоем примере в компиляторе CASE вполне достаточно.
А рассуждения в контексте надуманных задач считаю мало полезным занятием 

[adva]

Так. Давай по порядку. Что такое "подменил директорию"?

Это лучше в документации к ББ посмотреть: в исходниках это обычно экспортируемая переменная Dir и StdDir . StdDir это реализация для Dir по умолчанию, Dir можно устанавливать при выполнении программы

Если я конечно это правильно понял

Конечно в данное случае при разработке придется придерживаться каких то соглаешний

[kkkk]

Предлагаю увеличить масштаб. У тебя мегапроект.

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

[Geniepro]

А чем конкретно в данном случае ошибка компиляции лучше?

Всё, что может быть проверено во время компиляции -- должно проверяться во время компиляции.
Тесты -- работа для человека, а работать должен компьютер.
Компиляция тоже ведь своего рода тест на корректность программы, где-то слабый тест (в сях, например), где-то сильный (в системах доказательства теорем, например)...

[ilovb]

Да я ж не спорю. Но в данном случае это не является проблемой. Метод решения просто странный.

- Есть маленькая вероятность что HALT не сработает....
- Давайте вкрутим ООП чтобы исключить эту маленькую вероятность!

Это все равно что на одного фашиста целую атомную бомбу сбрасывать...

[valexey_u]

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

Я раньше тоже так думал. До тех пор пока не начал пользоваться. На практике же ситуация другая. HALT вылетает сразу. Причина банальна. Когда мы добавляем новое сообщение, то 100% мы его тестируем, т.е. делаем хотя бы 1 прогон с этим новым сообщением.
Если разраб свой код вообще не запускает и вываливает в продакшин, то да... беда.

У компилятора реально очень много веток и комбинаций. Мы УЖЕ сталкивались с ситуацией когда был халт у компилятора при компиляции программ пользователя (можно поискать по форуму - оно тут есть). На тестах и прогонах это не вылезало. А все потому, что js как раз следует этой модели - все проверки в рантайме, а не на этапе компиляции. Динамическая типизация, ага. Причем то был халт не из за опечатки, а именно из за того что именно не все возможные случаи были рассмотрены.

[ilovb]

А с ООП было бы по другому?

В общем не буду больше спорить. Но лично я пруфа не вижу.

ps Насчет динамической типизации... Все время слышу про проблемы с ней. Но сам не сталкиваюсь...
Несмотря на то, что написал далеко не один десяток тысяч строк кода на языке с динамической типизацией. Бывают, конечно, ошибки из-за нее, но слишком редко, чтобы считать это проблемой.

[adva]

Ага, если еще учесть, что обновления от 1с типовых конф, которые тестируются (ну или должны, я надеюсь), пекутся как пирожки. Как минимум усложнение "писанины" повлияет на количество этого кода , ну и соответственно меньше будет исправлений

[valexey_u]

Да, по решаемой задаче, я полагаю, что и ООП тут так себе подходит. То есть это не тот случай когда число произвольных подтипов должно быть неизвестно, это не случай когда нужна произвольная неподконтрольная расширяемость.

Тут, как мне кажется, вполне подойдет явный список типов перечисленных в одном месте (как собственно по факту и имеем в коде).

Основываясь на этом и буду ваять решение. Вроде бы кое-что придумалось.

[ilovb]

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

У модуля, который содержит абстрактный интерфейс, делается экспортная переменная, в которую втыкается текущая реализация по-умолчанию (фабрика)
Переменную обычно называют Dir.
Также есть умолчательная фабрика StdDir.

Код: [Выделить]

BlackBox uses special objects with factory methods,
so-called factory objects. In BlackBox, factory objects are
used in a particular way: they are installed in global variables
and may be replaced at run-time, without affecting client code.
For historical reasons, we call factory objects which are used
for configuration purposes directory objects.
ps Ну это шаблон ООП ессесно.

[valexey_u]

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

У модуля, который содержит абстрактный интерфейс, делается экспортная переменная, в которую втыкается текущая реализация по-умолчанию (фабрика)
Переменную обычно называют Dir.
Также есть умолчательная фабрика StdDir.

Код: [Выделить]

BlackBox uses special objects with factory methods,
so-called factory objects. In BlackBox, factory objects are
used in a particular way: they are installed in global variables
and may be replaced at run-time, without affecting client code.
For historical reasons, we call factory objects which are used
for configuration purposes directory objects.
ps Ну это шаблон ООП ессесно.

Это решение вообще никакого отношения не имеет к обсуждаемой задаче. Ну, то есть просто не в тему :-)

[ilovb]

Я просто пояснил, о чем говорил adva.