Борис Рюмшин писал(а):
Можно и проголосовать.
Есть на форуме голосовалка?
Только вот текст для голосования надо обсудить коллективно.
У Хельмута есть документ с описанием различий
http://www.zinnamturm.eu/pac/BlackBox-2 ... Center.txtB01: HostFiles.NewWriter "returns" Trap 21 instead of NIL
viewtopic.php?t=1948viewtopic.php?t=6169issue-#22: HostFiles.NewWriter violating the specification
https://forum.blackboxframework.org/viewtopic.php?t=77https://redmine.blackboxframework.org/issues/22https://forum.blackboxframework.org/viewtopic.php?t=170Через гугл транслейт
Код:
Реализация HostFiles.NewWriter нарушает спецификацию. Согласно спецификации (System / Docu / Files) в случае файлов только для чтения NewWriter должен возвращать NIL. Однако реализация BlackBox 1.6 генерирует трап. Спецификацию необходимо согласовать с реализацией.
Об этом сообщает Илья Ермаков, 2009-10-12.
Oberon Core или Framework Center?
Решение Oberon Core согласовало реализацию (HostFiles) со спецификацией (Files).
Решение BlackBox Framework Center (Проблема № 22) согласовало спецификацию (Файлы) с реализацией (HostFiles). Чтобы избежать TRAP, следует ввести два новых метода File (Shared () и Closed ()), которые возвращают текущее состояние файла.
Заметки
Иван Денисов
Аргумент состоял в том, что невозможно узнать, есть ли общий доступ к файлу или нет, с помощью фреймворка. Вот почему эта ловушка становится неизбежной.
В документации по файлам есть одно правило.
Открытие файла в общем режиме - это правило BlackBox; открытие файла в монопольном режиме - нечастое исключение.
Итак, эта проблема не должна возникнуть, если вы следуете этому правилу.
Однако как предотвратить TRAP в редких исключениях? Это означает, что программист должен предоставить эту проверку с помощью собственных переменных модуля и обеспечить строгую инкапсуляцию переменных файлов.
Один файл можно открыть с помощью dir.Old, другой - с помощью dir.New. Вы не можете отличить, создаете ли вы file.NewWriter или нет, имея только переменную Files.File.
Решение центра
Йозеф Темпл
Проверяя возвращаемое значение NIL, вы не можете увидеть, доступен ли файл для записи или нет. Почему? Потому что, если системе не хватает памяти, она также возвращает NIL при вызове NEW. Так что возвращение NIL не решает проблемы, кстати, весьма экзотической. Я никогда не испытывал этого и с трудом могу представить, что это актуально на практике. Обычно вы все равно знаете, что делаете со своими файлами.
Если это действительно важно, правильным решением было бы предоставить функцию получения, которая возвращает общее состояние файла. Поскольку возвращаемая информация соответствует параметру «общий» для «Старый», я бы назвал его Shared (), а не Writeable (). Это сделало бы соответствие параметра и геттера явным.
Та же проблема возникает с закрытыми файлами. Насколько мне известно, нет возможности узнать, был ли файл закрыт или нет. Опять же, это не было проблемой в течение многих лет, но это такая же проблема, как и с общими файлами.
Теперь мы можем ввести еще один метод получения с именем Closed (), но если его никто не вызывает, то действительно вопрос, нужен ли он нам вообще и нужен ли он сейчас. Однако, если мы вводим одно, мы должны вводить и другое. Аргумент в пользу их введения сейчас состоит в том, что теперь мы все равно делаем несовместимые двоичные файлы, требуя перекомпиляции всех пользовательских модулей. Таким образом, это изменение не вызовет дополнительной нагрузки на пользователей.
Если есть необходимость в проверке общего или закрытого состояния файла, для этой цели должны быть новые методы функций, естественно названные IsClosed (): BOOLEAN и IsShared (): BOOLEAN.
Возврат NIL, конечно, не является правильным исправлением, потому что NIL также возвращается в случае переполнения кучи.
В дополнение к удалению одного предложения из спецификации, мы должны добавить предварительное условие, которое определяет допустимые состояния при вызове NewWriter.
Вероятно, будет полезно иметь функции Closed () и Shared (), доступные при указании предварительного условия.
Closed () и Shared () относятся к состояниям «закрытый» и «общий». Следовательно, общий доступ подразумевает НЕ закрытый. Это позволяет выполнить проверку предусловия перед вызовом NewWriter и, таким образом, избежать TRAP, если предусловие не выполнено. Это используется редко (никогда), но для полноты картины я бы поддержал их включение.
Это также упростило бы указание предусловия:
Предварительно:
~ f.Closed () 20
~ f.Shared () 21
Энде.