OberonCore
https://forum.oberoncore.ru/

#042 Поправка в StdFolds
https://forum.oberoncore.ru/viewtopic.php?f=134&t=6685		 Страница 1 из 1
Автор:  adimetrius [ Суббота, 28 Ноябрь, 2020 15:40 ]
Заголовок сообщения:  #042 Поправка в StdFolds
Коллеги,

в стандартном каркасе тип StdFolds.Fold объявлен как нерасширяемый, а тип StdFolds.Directory - как абстрактный. Получается, невозможно сделать альтернативную реализацию складок, но альтернативную директорию - можно.

Предлагаю сделать, как принято в других местах каркаса:

Fold* = POINTER TO ABSTRACT RECORD...END;
StdFold = POINTER TO RECORD (Fold) ... END;

чтобы можно было делать альтернативные реализации складок, а главное - модули, которые с любыми реализациями смогут работать.
Автор:  Info21 [ Воскресенье, 29 Ноябрь, 2020 13:39 ]
Заголовок сообщения:  Re: Поправка в StdFolds
Поддерживаю.
Автор:  adimetrius [ Пятница, 22 Январь, 2021 00:08 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Я попытался было наскоком поменять интерфейс StdFolds.Fold. Сделать его абстрактным и со стандартной реализацией. Оказалось, это возможно ценой потери совместимости со ВСЕМИ существующими документами!!! Ведь из odc читается StdFolds.Fold. В документе старый Fold, а в памяти ЭВМ - другой (новый) модуль с абстрактным Fold и конкретным StdFold. (По ходу дела обнаружилась брешь в защите где-то в Stores: обычными средствами невозможно создать экземпляр абстрактной записи; но Stores преспокойно таковой создавал.) Так вот, в документе-контейнере записан экземпляр StdFOlds.Fold^, модуль Stores создает пустой экземпляр такового. А в "новом" мире не должно быть переменных StdFolds.Fold^, должны быть StdFolds.StdFold^. Но взяться им неоткуда: при загрузке Stores уже создал переменную типа StdFolds.Fold, и переделать ее в StdFolds.StdFold невозможно; можно новую создать нужного типа, но как сообщить Stores, что теперь нужно ее использовать?
Поскольку терять совместимость со ВСЕМИ документами я был не готов, пришлось довольствоваться менее общим решением - я просто под свои нужды переделал функциональность StdFolds.Fold, оставив их без абстрактного базового класса.
Но какое обобщенное решение предложить? Ума не приложу.
(Я пробовал схитрить: назвал базовый тип StdFolds.BaseFolds, а конкретное расширение - просто StdFolds.Fold, в надежде, что Stores создаст экземпляр нужного типа. Не тут то было: здесь защита сработала: в контейнер записывается не просто имя типа, а вся его "генеалогия" - все базовые типы по порядку. И моя хитрость не прошла)

При этом, в архитектуру ББ заложена всем нам известная возможность для версионной миграции: если бы изначально StdFolds.Fold был абстрактным, то в файлы-контейнеры записывался бы экземпляр StdFolds.StdFold с номером версии, и более новые версии модулей могли бы легко прочесть старые версии данных и адаптировать их.

Но вот для предпринятой мной версионной миграции неабстрактного интерфейса в ББ средств не оказалось. Я даже затрудняюсь как-то классифицировать этот случай...
Вот есть процедура (s: Store) ExternalizeAs. Быть может, что-то типа InteralizeAs... Но как быть с гарантиями читателю?..

С другой стороны, может, это и правильно? Ведь если меняются интерфейсы некоего компонента, то его клиенты должны быть, по крайней мере, перекомпилированы. Но я перекомпилировал весь ББ с новым абстрактным интерфейсом складок...

Одним словом, непонятно, как "провернуть" такую миграцию.
Автор:  Александр Ильин [ Пятница, 22 Январь, 2021 01:49 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Похоже, что вам надо делать свою новую реализацию расширяемых складок, и забыть про совместимость, раз уж её тут не заложили.
Сделайте функцию, которая будет проходить по документу и заменять стандартные вкладки на ваши расширяемые.
Автор:  Trurl [ Пятница, 22 Январь, 2021 10:25 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
А никакой разницы, делать расширение типа или полностью новый тип. В любом случае потеряется совместимость со ВСЕМИ существующими документами.
Автор:  Илья Ермаков [ Пятница, 22 Январь, 2021 10:40 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Для Stores нужно доработать какое-то решение, когда настраиваются фабрики для имён типов для создания при загрузке.
Что-то такое нужно.
Уже натыкались не раз на то, что в этом месте он "докомпонентный" остался (пришёл из периода до перевода ББ на паттерны с фабриками и реализациями).
Автор:  adimetrius [ Пятница, 22 Январь, 2021 14:53 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Александр Ильин писал(а):
Похоже, что вам надо делать свою новую реализацию расширяемых складок, и забыть про совместимость, раз уж её тут не заложили.
Сделайте функцию, которая будет проходить по документу и заменять стандартные вкладки на ваши расширяемые.

Да, это я тоже рассматривал. Но что если игла в яйце, яйцо в утке, утка в зайце, заяц в чемодане, а чемодан - это контейнер odc? И все они в то же время - черные ящики?

Т.е. кмк такое решение в ряде частных случаев подойдет, но не как общее решение для миграции версий в системе с компонентами-черными ящиками.
Автор:  Илья Ермаков [ Пятница, 22 Январь, 2021 17:16 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
В принципе, объекты-расширения Stores всегда готовы к созданию через NEW и дальнейшей загрузке из потока.

Достаточным представляется решение, когда есть конфигурация соответствия - имя типа в файле => имя реального типа, который инстанциируется модулем Stores как альтернативная реализация.
Автор:  Иван Денисов [ Пятница, 22 Январь, 2021 17:20 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Не так страшно, если в какой-то момент придется перекодировать файлы, тогда и складки заменить на новые. Ведь и формат текстовых файлов желательно улучшить. Пробелы хранятся как отдельные куски в русских/юникодных текстах.
Всё равно надо сделать какой-то инструмент для миграции.
1.5->1.8
1.6->1.8
1.7->1.8
Чтобы не только складки заменились, но и замены в коде для некоторых процедур.
Strings.Upper -> Unicode.Upper
и др.
Автор:  SovietPony [ Пятница, 22 Январь, 2021 18:25 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Как насчет того что бы Fold оставить для совместимости (загрузки из доккумента) и создать в дополнение новый абстрактный тип, который уже будет создаваться для новых документов?
Автор:  Trurl [ Пятница, 22 Январь, 2021 21:11 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Илья Ермаков писал(а):
Уже натыкались не раз на то, что в этом месте он "докомпонентный" остался (пришёл из периода до перевода ББ на паттерны с фабриками и реализациями).

Как раз не "остался", а наоборот. В Обероне в документе записывается имя процедуры-генератора, а она сама решает, какого типа объект создать.
Автор:  Илья Ермаков [ Пятница, 22 Январь, 2021 21:17 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Ну я имел в виду не в плане "от Оберона".

Stores имеет внутри много хвостов ещё от системы типов Oberon-2, т.е. он очень древний в самом ББ.
А ББ не сразу был по всем паттернам выстроен.
Автор:  Trurl [ Пятница, 22 Январь, 2021 21:45 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Ну вот эту схему специально для ББ придумали. Может, это и есть компонентность: вот вам чёрный ящик, пользуйтесь на здоровье, а расширять его нечего?
Автор:  Евгений Темиргалеев [ Понедельник, 25 Январь, 2021 02:34 ]
Заголовок сообщения:  Re: #042 Поправка в StdFolds
Решение
1) Сделать отдельную версию новых "правильных" складок с сохранением старой "неправильной", это обеспечит совместимость для "старых" документов.
2) "Неправильная" должна себя выгружать себя через ExternalizeAs как "новая", это обеспечит постепенную миграцию при сохранении документов.
Дополнительно можно сделать общую тулзу, которая проходит данному каталогу и пересохраняет все документы. Она обеспечит миграцию всех документов сразу для тех, кому надо.

P.S. Есть еще способ преобразования -- настраиваемый внешний конвертор для Stores. Он позволяет организовывать миграцию при пересохранении независимо от вьюшек.
https://oberoncore.ru/library/temir_pre ... dokumentov
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/