манипуляция провайдерами настроек через совет другого мастера#139
Open
Segate-ekb wants to merge 9 commits into
Open
манипуляция провайдерами настроек через совет другого мастера#139Segate-ekb wants to merge 9 commits into
Segate-ekb wants to merge 9 commits into
Conversation
Co-authored-by: Copilot <copilot@github.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughВводится ленивый построитель конфигурации параметров ChangesПостроитель менеджера параметров
Файловый метапровайдер
Интеграция и инициализация
Документация и индекс
Форматирование
Зависимости
Sequence Diagram(s)sequenceDiagram
participant Поделка as Поделка
participant СДМ as СоветДругогоМастера
participant Строитель as СтроительМенеджераПараметров
participant Метапров as ФайловыйМетапровайдер
participant МП as МенеджерПараметров
Note over Поделка,МП: Новый поток (после PR)
Поделка->>СДМ: ПолучитьСтроительМенеджераПараметров()
activate СДМ
СДМ->>Строитель: ленивое создание/возврат кэша
activate Строитель
Строитель->>МП: создать/получить МенеджерПараметров()
activate МП
Строитель->>МП: добавить env-провайдер (приоритет 1)
Строитель->>Метапров: создать файловый метапровайдер (форматы: yaml/json/ini)
activate Метапров
Метапров->>МП: зарегистрировать физические провайдеры для каждого формата
Метапров-->>Строитель: метапровайдер готов
deactivate Метапров
Строитель->>МП: добавить inline/прочие провайдеры
deactivate МП
Строитель-->>СДМ: вернуть построитель
deactivate Строитель
SДМ->>Строитель: применить устаревшие настройки, если явно заданы
Строитель->>МП: обновить конфигурацию (при необходимости)
SДМ-->>Поделка: вернуть построитель
deactivate СДМ
Поделка->>Строитель: МенеджерПараметров()
Поделка->>МП: Прочитать()
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
docs/api/050-Классы/25-СтроительМенеджераПараметров.md (1)
221-221: Небольшая языковая правка для естественности формулировки.Фразу можно сделать чище: “Проксирует настройки сразу во все физические провайдеры”.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/api/050-Классы/25-СтроительМенеджераПараметров.md` at line 221, Заменить фразу в описании, чтобы звучала естественнее: изменить текст "Проксирует настройки сразу в физические провайдеры (`<база>-yaml`, `<база>-json`, `<база>-ini`)" на "Проксирует настройки сразу во все физические провайдеры (`<база>-yaml`, `<база>-json`, `<база>-ini`)" в блоке, описывающем методы ДобавитьПровайдерФайлов / ПровайдерФайлов.tests/СтроительМенеджераПараметров.os (1)
128-146: Добавьте проверку расширения.ymlв тест определения формата.Сейчас в этом сценарии закреплены
.yaml/.json/.ini, но не.yml. Имеет смысл добавить отдельный кейс, чтобы не потерять поддержку альтернативного YAML-расширения при будущих изменениях.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/СтроительМенеджераПараметров.os` around lines 128 - 146, В тесте Процедура ДобавитьПровайдерФайлНастроекОпределяетФорматПоРасширению добавьте ещё один вызов Строитель.ДобавитьПровайдерФайлНастроек с путём, оканчивающимся на ".yml" и отдельную проверку Ожидаем.Что(Строитель.Провайдер("yml")).Не_().Равно(Неопределено) и проверку, аналогичную НастройкиY.ПутьКФайлуПараметров, чтобы убедиться, что формат для .yml определяется корректно; используйте существующие методы Провайдер и Настройки() для точной локализации изменений.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/api/050-Классы/25-СтроительМенеджераПараметров.md`:
- Line 9: В документации заменить некорректный вызов метода
СоветДругогоМастера.СтроительМенеджераПараметров() на актуальный
СоветДругогоМастера.ПолучитьСтроительМенеджераПараметров() в примерах
(упоминания в строках с вызовом и ссылках, напр. на строках с вызовом и в
анкорах), чтобы пример соответствовал реалиям API и тестам; проверьте и обновите
связанные ссылки/якоря (например
20-СоветДругогоМастера.md#СтроительМенеджераПараметров) так, чтобы они указывали
на ПолучитьСтроительМенеджераПараметров.
In `@packagedef`:
- Line 19: The package definition currently depends on an unpublished configor
version (.ЗависитОт("configor", "0.12.0")), which makes installs fail; update
the dependency to the latest published version by changing the .ЗависитОт call
for "configor" to use "0.11.1" (or revert to "0.12.0" later once it is
published) so the packagedef is resolvable.
In `@src/internal/Классы/СтроительМенеджераПараметров.os`:
- Around line 161-168: УдалитьПровайдер сейчас только вызывает
Метапровайдер.Отключить() и удаляет запись из _ФайловыеМетапровайдеры, но не
удаляет физические базовые провайдеры в _МенеджерПараметров, поэтому повторный
ДобавитьПровайдерФайлов("default",...) вызывает коллизии и старые обёртки в
ФайловыйМетапровайдер.ПриСозданииОбъекта(); исправьте УдалитьПровайдер так,
чтобы после Метапровайдер.Отключить() также удалялись все связанных с этим
метапровайдером физические провайдеры из _МенеджерПараметров (например по id или
по ссылке), либо вместо удаления просто пересобирали/реинициализировали
_МенеджерПараметров без удаляемого провайдера, чтобы при следующем
ДобавитьПровайдерФайлов не осталось старых записей и не возникли коллизии
идентификаторов.
In `@src/internal/Классы/ФайловыйМетапровайдер.os`:
- Around line 111-118: УстановитьФайлПараметров сейчас передаёт один и тот же
ПутьКФайлу каждому провайдеру из коллекции Провайдеры, что ломает multi-format
сценарии (например одинаковый путь попадает в yaml, json и ini провайдеры);
исправьте это либо запретив вызов УстановитьФайлПараметров когда в Провайдеры
зарегистрировано более одного формата (кинуть ошибку/лог), либо изменить логику
так, чтобы УстановитьФайлПараметров не распределял путь по всем провайдерам и
оставить возможность задавать конкретный путь только через
ДобавитьПровайдерФайлНастроек(…) — внесите проверку количества/типа провайдеров
в функцию УстановитьФайлПараметров и действуйте согласно выбранной политике.
In `@src/Классы/СоветДругогоМастера.os`:
- Around line 44-76: Функция ПолучитьСтроительМенеджераПараметров всегда создаёт
новый экземпляр, из‑за чего внешние изменения строителья теряются; исправьте это
в классе СоветДругогоМастера, сохранив строитель в поле (например,
this.СтроительМенеджераПараметров) и возвращая существующий экземпляр при
повторных вызовах вместо всегда Нового; при первом вызове создайте и настройте
Строитель как сейчас, затем кешируйте его; обновите также сценарий
ИнициализироватьМенеджерПараметров/Поделка, если он ожидал делиться тем же
объектом, и добавьте регрессионный тест, который берёт строитель из
СоветДругогоМастера, модифицирует провайдеры и затем передаёт
СоветДругогоМастера в Поделка, ожидая сохранить изменения.
---
Nitpick comments:
In `@docs/api/050-Классы/25-СтроительМенеджераПараметров.md`:
- Line 221: Заменить фразу в описании, чтобы звучала естественнее: изменить
текст "Проксирует настройки сразу в физические провайдеры (`<база>-yaml`,
`<база>-json`, `<база>-ini`)" на "Проксирует настройки сразу во все физические
провайдеры (`<база>-yaml`, `<база>-json`, `<база>-ini`)" в блоке, описывающем
методы ДобавитьПровайдерФайлов / ПровайдерФайлов.
In `@tests/СтроительМенеджераПараметров.os`:
- Around line 128-146: В тесте Процедура
ДобавитьПровайдерФайлНастроекОпределяетФорматПоРасширению добавьте ещё один
вызов Строитель.ДобавитьПровайдерФайлНастроек с путём, оканчивающимся на ".yml"
и отдельную проверку
Ожидаем.Что(Строитель.Провайдер("yml")).Не_().Равно(Неопределено) и проверку,
аналогичную НастройкиY.ПутьКФайлуПараметров, чтобы убедиться, что формат для
.yml определяется корректно; используйте существующие методы Провайдер и
Настройки() для точной локализации изменений.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b767da23-3a06-440d-9c69-b14878bf8386
📒 Files selected for processing (10)
docs/api/050-Классы/20-СоветДругогоМастера.mddocs/api/050-Классы/25-СтроительМенеджераПараметров.mddocs/api/index.mdpackagedefsrc/internal/Классы/СтроительМенеджераПараметров.ossrc/internal/Классы/ФайловыйМетапровайдер.ossrc/Классы/Поделка.ossrc/Классы/СоветДругогоМастера.ostests/СоветДругогоМастера.ostests/СтроительМенеджераПараметров.os
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/Классы/СоветДругогоМастера.os (1)
57-176:⚠️ Potential issue | 🟠 MajorКешированный строитель не синхронизируется с поздними legacy-сеттерами.
Сейчас legacy-настройки попадают в
_Строительтолько при первом создании. Если кто-то уже получил строитель, а потом вызоветЗначенияДеталек(...)/ПрефиксПеременныхСреды(...)/ИмяФайлаСоЗначениямиДеталек(...), cached instance останется со старыми значениями. Это делает порядок вызовов публичного API наблюдаемым и ломает обратную совместимость.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/Классы/СоветДругогоМастера.os` around lines 57 - 176, Кешированный _Строитель в функции ПолучитьСтроительМенеджераПараметров не синхронизируется с устаревшими сеттерами (ЗначенияДеталек, ПрефиксПеременныхСреды, ИмяФайлаСоЗначениямиДеталек, ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек): если _Строитель уже создан, последующие вызовы этих методов не влияют на него; исправьте это либо инвалидируя кеш (_Строитель = Неопределено) внутри каждого legacy-сеттера после установки значений, либо (лучше) сразу применять изменения к уже существующему строителю — получить текущий Строитель через ПолучитьСтроительМенеджераПараметров() и обновить провайдеры/метапровайдер (вызовы Провайдер("env").Настройки().УстановитьПрефикс, УдалитьПровайдер("inline")/ДобавитьПровайдерСоответствие, ПровайдерФайлов("default").УстановитьИмяФайла/УстановитьСтандартныеКаталогиПоиска) чтобы состояние всегда оставалось согласованным.
🧹 Nitpick comments (1)
tests/СоветДругогоМастера.os (1)
180-230: Добавьте кейс для позднего вызова legacy-сеттера.Текущие тесты покрывают только сценарий “сначала выставили устаревшую настройку, потом создали строитель”. Если кеш строителя остаётся частью контракта, стоит зафиксировать и обратный порядок: сначала
ПолучитьСтроительМенеджераПараметров(), потом legacy-сеттер, чтобы было ясно, должен ли кеш обновляться или этот сценарий больше не поддерживается.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@tests/СоветДругогоМастера.os` around lines 180 - 230, Добавьте тесты, проверяющие поведение при позднем вызове устаревших сеттеров: создайте новый тест (например ПрименитьУстаревшиеНастройкиПрефиксENV_ПослеПолученияСтроителя и аналогичные для ИмяФайлаСоЗначениямиДеталек и ЗначенияДеталек) где сначала вызывается Совет.ПолучитьСтроительМенеджераПараметров(), затем вызываются Совет.ПрефиксПеременныхСреды("MYAPP") / Совет.ИмяФайлаСоЗначениямиДеталек("my-config") / Совет.ЗначенияДеталек(Значения) и после этого проверяется, обновился ли кеш/строитель: читать из Строитель.Провайдер(...).Настройки().ПолучитьПрефикс() или Строитель.Провайдер("default-json").Настройки().ПолучитьНастройки() и Менеджер = Строитель.МенеджерПараметров(); Менеджер.Прочитать(); Ожидаем.Что(Менеджер.Параметр("ключ")).Равно("значение") — чтобы зафиксировать ожидаемое поведение при позднем сеттинге.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/Классы/СоветДругогоМастера.os`:
- Around line 182-189: Измените текст в процедуре ПредупредитьОбУстаревшемМетоде
класса СоветДругогоМастера, чтобы не предлагать «передавая строитель в
конструктор Поделки» (это неверно для текущего публичного API). Переформулируйте
предупреждение так, чтобы рекомендовать использовать
СтроительМенеджераПараметров при создании или конфигурации самого
СоветДругогоМастера (или явно указать правильный точка интеграции), упомянув
правильные символы: СоветДругогоМастера, Поделка и СтроительМенеджераПараметров,
чтобы пользователи получили корректную инструкцию по миграции.
---
Outside diff comments:
In `@src/Классы/СоветДругогоМастера.os`:
- Around line 57-176: Кешированный _Строитель в функции
ПолучитьСтроительМенеджераПараметров не синхронизируется с устаревшими сеттерами
(ЗначенияДеталек, ПрефиксПеременныхСреды, ИмяФайлаСоЗначениямиДеталек,
ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек): если _Строитель уже
создан, последующие вызовы этих методов не влияют на него; исправьте это либо
инвалидируя кеш (_Строитель = Неопределено) внутри каждого legacy-сеттера после
установки значений, либо (лучше) сразу применять изменения к уже существующему
строителю — получить текущий Строитель через
ПолучитьСтроительМенеджераПараметров() и обновить провайдеры/метапровайдер
(вызовы Провайдер("env").Настройки().УстановитьПрефикс,
УдалитьПровайдер("inline")/ДобавитьПровайдерСоответствие,
ПровайдерФайлов("default").УстановитьИмяФайла/УстановитьСтандартныеКаталогиПоиска)
чтобы состояние всегда оставалось согласованным.
---
Nitpick comments:
In `@tests/СоветДругогоМастера.os`:
- Around line 180-230: Добавьте тесты, проверяющие поведение при позднем вызове
устаревших сеттеров: создайте новый тест (например
ПрименитьУстаревшиеНастройкиПрефиксENV_ПослеПолученияСтроителя и аналогичные для
ИмяФайлаСоЗначениямиДеталек и ЗначенияДеталек) где сначала вызывается
Совет.ПолучитьСтроительМенеджераПараметров(), затем вызываются
Совет.ПрефиксПеременныхСреды("MYAPP") /
Совет.ИмяФайлаСоЗначениямиДеталек("my-config") / Совет.ЗначенияДеталек(Значения)
и после этого проверяется, обновился ли кеш/строитель: читать из
Строитель.Провайдер(...).Настройки().ПолучитьПрефикс() или
Строитель.Провайдер("default-json").Настройки().ПолучитьНастройки() и Менеджер =
Строитель.МенеджерПараметров(); Менеджер.Прочитать();
Ожидаем.Что(Менеджер.Параметр("ключ")).Равно("значение") — чтобы зафиксировать
ожидаемое поведение при позднем сеттинге.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ea1ce1df-9476-4014-b4d9-3d8a55f0ba63
📒 Files selected for processing (5)
docs/api/050-Классы/25-СтроительМенеджераПараметров.mdsrc/internal/Классы/ФайловыйМетапровайдер.ossrc/Классы/СоветДругогоМастера.ostests/СоветДругогоМастера.ostests/СтроительМенеджераПараметров.os
🚧 Files skipped from review as they are similar to previous changes (2)
- tests/СтроительМенеджераПараметров.os
- src/internal/Классы/ФайловыйМетапровайдер.os
sfaqer
requested changes
May 4, 2026
| ``` | ||
|
|
||
| ## ЗначенияДеталек | ||
| ## ПолучитьСтроительМенеджераПараметров |
Member
There was a problem hiding this comment.
Мне кажется нейминг методов нужно получше подобрать, потому что для меня:
СтроительМенеджераПараметров и ПолучитьСтроительМенеджераПараметров это буквально одно и то же, и ожидать от обоих методов я буду тоже самое поведение, ну и выяснив что их вообще 2 я в ступор впаду
|
|
||
| ## ЗначенияДеталек <Badge type="warning" text="устарело" /> | ||
|
|
||
| Используйте `СтроительМенеджераПараметров().ДобавитьПровайдерСоответствие(...)` (с предварительным `УдалитьПровайдер("inline")` при замене дефолтного inline-провайдера). |
Member
There was a problem hiding this comment.
Мне кажется это болезненный паттерн, ну типа со схемой запроса в 1С. которая при создании уже имеет пустой оператор по нулевому индексу и вместо того чтобы начать работать с классом по человечески нужно либо удалять этот добавленный дефолт либо его самого мутировать, каждый раз спина горит.
Может вот это удаление под капотом как-то будет работать или параметризировать хотя бы как нибудь типа добавлять\не добавлять дефолт?
| // Возвращаемое значение: | ||
| // МенеджерПараметров | ||
| // | ||
| Функция МенеджерПараметров() Экспорт |
Member
There was a problem hiding this comment.
Кажется нет смысла это наружу выставлять, если этот класс работает проксёй для конфигора то пусть делает это до конца.
| // Регистрирует ПровайдерПараметровСоответствие с заданными значениями. | ||
| // | ||
| // Параметры: | ||
| // Значения - Соответствие - значения параметров (по умолчанию пустое) |
Member
There was a problem hiding this comment.
А какая смысловая нагрузка у этого дефолта?
| // ФайловыйМетапровайдер | ||
| // | ||
| Функция ДобавитьПровайдерФайлов(Знач Идентификатор, | ||
| Знач Приоритет, |
Member
There was a problem hiding this comment.
Кажется странным что у всех провайдеров приоритет не обязательный параметр а тут обязательный
| Возврат Новый ПровайдерПараметровINI; | ||
| КонецЕсли; | ||
|
|
||
| ВызватьИсключение СтрШаблон("Неизвестный формат файлового провайдера: <%1>", Формат); |
Member
There was a problem hiding this comment.
Кажется это недостижимый код, ОпределитьФорматПоРасширению уже упадёт если формат не угадается
| ФайловыйПровайдерПоУмолчанию.УстановитьИмяФайла("autumn-properties"); | ||
| ФайловыйПровайдерПоУмолчанию.УстановитьСтандартныеКаталогиПоиска("src"); | ||
|
|
||
| ДобавитьПровайдерСоответствие(, 3, "inline"); |
Member
There was a problem hiding this comment.
А вот это вот зачем вообще нужно? Оо
| @@ -17,22 +20,93 @@ | |||
| // | |||
| Перем ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек; | |||
|
|
|||
| // Соответствие: имя устаревшего поля -> Истина, если поле явно установлено через сеттер. | |||
Comment on lines
+185
to
+187
| "Метод СоветДругогоМастера.%1(...) устарел." | ||
| " Используйте СтроительМенеджераПараметров.%2," | ||
| " передавая строитель в конструктор Поделки.", |
Member
There was a problem hiding this comment.
Лучше в одну строку, а то в логах ад будет.
|
|
||
| Процедура ПредупредитьОбУстаревшемМетоде(Знач ИмяМетода, Знач РекомендуемаяЗамена) | ||
|
|
||
| Лог.Предупреждение(СтрШаблон( |
Member
There was a problem hiding this comment.
Лог.Предупреждение() сам по себе уже СтрШаблон, первым параметром передаётся шаблон последующими значения параметров
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/api/050-Классы/20-СоветДругогоМастера.md`:
- Line 57: Документальная строка предлагает заменить вызов
ДополнительныйКаталогПоиска на
ПолучитьСтроительМенеджераПараметров().ПровайдерФайлов("default").УстановитьСтандартныеКаталогиПоиска(...),
но названия методов отличаются по семантике: УстановитьСтандартныеКаталогиПоиска
заменяет список, тогда как ДополнительныйКаталогПоиска добавлял один каталог;
проверьте поведение реализации: если нужно добавлять каталоги — заменить на
ДобавитьКаталогПоиска, иначе если требуется полностью заменить набор — оставить
УстановитьСтандартныеКаталогиПоиска и явно документировать, что поведение
отличается, обновив пример и описание в тексте.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 8ba24649-e2a6-4da6-aa6a-f05a73cc8c30
📒 Files selected for processing (6)
docs/api/050-Классы/20-СоветДругогоМастера.mdsrc/internal/Классы/СтроительМенеджераПараметров.ossrc/Классы/Поделка.ossrc/Классы/СоветДругогоМастера.ostests/СоветДругогоМастера.ostests/СтроительМенеджераПараметров.os
🚧 Files skipped from review as they are similar to previous changes (4)
- src/Классы/Поделка.os
- src/Классы/СоветДругогоМастера.os
- tests/СоветДругогоМастера.os
- src/internal/Классы/СтроительМенеджераПараметров.os
| ## ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек | ||
| ## ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек <Badge type="warning" text="устарело" /> | ||
|
|
||
| Используйте `ПолучитьСтроительМенеджераПараметров().ПровайдерФайлов("default").УстановитьСтандартныеКаталогиПоиска(...)`. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Поиск методов управления каталогами поиска
rg -n "УстановитьСтандартныеКаталогиПоиска|ДобавитьКаталог" -g "*.os" -C 3Repository: autumn-library/autumn
Length of output: 4010
Проверьте семантическую корректность пути миграции.
Метод УстановитьСтандартныеКаталогиПоиска существует, но его название (УстановитьСтандартные — "установить/заменить стандартные") семантически отличается от названия устаревшего метода ДополнительныйКаталогПоиска (добавление дополнительного).
В codebase также имеется метод ДобавитьКаталогПоиска, который по названию лучше соответствует поведению устаревшего метода (добавление vs. установка). Убедитесь, что предлагаемая миграция на УстановитьСтандартныеКаталогиПоиска действительно эквивалентна старому поведению, или рассмотрите использование ДобавитьКаталогПоиска вместо неё.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/api/050-Классы/20-СоветДругогоМастера.md` at line 57, Документальная
строка предлагает заменить вызов ДополнительныйКаталогПоиска на
ПолучитьСтроительМенеджераПараметров().ПровайдерФайлов("default").УстановитьСтандартныеКаталогиПоиска(...),
но названия методов отличаются по семантике: УстановитьСтандартныеКаталогиПоиска
заменяет список, тогда как ДополнительныйКаталогПоиска добавлял один каталог;
проверьте поведение реализации: если нужно добавлять каталоги — заменить на
ДобавитьКаталогПоиска, иначе если требуется полностью заменить набор — оставить
УстановитьСтандартныеКаталогиПоиска и явно документировать, что поведение
отличается, обновив пример и описание в тексте.
Coverage Report for CI Build 27148541593Coverage decreased (-1.4%) to 87.49%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions3 previously-covered lines in 3 files lost coverage.
Coverage Stats
💛 - Coveralls |
Segate-ekb
force-pushed
the
feature/advice
branch
from
e5c650b to
02706f5
Compare
nixel2007
reviewed
Jun 10, 2026
| ## ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек | ||
| ## ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек <Badge type="warning" text="устарело" /> | ||
|
|
||
| Используйте `ПолучитьСтроительМенеджераПараметров().ПровайдерФайлов("default").УстановитьСтандартныеКаталогиПоиска(...)`. |
Member
There was a problem hiding this comment.
а они семантически одинаковые? УстановитьСтандартныеКаталогиПоиска добавляет каталог или заменяет их?
Member
|
Может переименовать тогда?
чт, 11 июн. 2026 г., 09:39 Ivanov Egor ***@***.***>:
… ***@***.**** commented on this pull request.
------------------------------
In docs/api/050-Классы/20-СоветДругогоМастера.md
<#139 (comment)>
:
> Функция ИмяФайлаСоЗначениямиДеталек(НовоеЗначение = Неопределено) Экспорт
```
-## ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек
+## ДополнительныйКаталогПоискаФайлаСоЗначениямиДеталек <Badge type="warning" text="устарело" />
+
+Используйте `ПолучитьСтроительМенеджераПараметров().ПровайдерФайлов("default").УстановитьСтандартныеКаталогиПоиска(...)`.
Добавляет каталог - да
—
Reply to this email directly, view it on GitHub
<#139?email_source=notifications&email_token=AAIUSKDDZSAAPROKTYSWPUT47JO3NA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTINBXGQ3DQMRXGIZKM4TFMFZW63VQOJSXM2LFO5PXEZLROVSXG5DFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#discussion_r3394122373>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIUSKHIYZLS6CX4JH4UZPL47JO3NAVCNFSNUABFKJSXA33TNF2G64TZHM2DQMJZGQ4DKMZRHNEXG43VMU5TIMZUGY2TSNZVGU2KC5QC>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Требует oscript-library/configor#49
Если вкратце:
Инкапсулировал билдер менеджера параметров в отдельной абстракции.
Теперь есть возможность управлять настройками гибко. Переопределять приоритеты чтения, добавлять, изменять и удалять провайдеры.
Пример: