OberonCore

Сейчас параметры каждым модулем читаются напрямую: HostFiles, HostFiles64, HostPackedFiles (Linux), HostMenus, у меня есть еще другие.

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

Возможный интерфейс.


Механизмы чтения параметров могут варьироваться в зависимости от системы. Например, в винде "/key".

Пока реализовал и использую эту схему без HostMenus.

Для HostMenus необходимо решить вопрос повторения ключей, когда при повторении имени они агрегируются в массив. Это можно по-разному
Например космтрока
blackbox -o file1.odc -o file2.odc
Подается в отмеченном интерфейсе как параметры o[0]=file1.odc o[1]=file2.odc.

Можно интерфейс расширить индексом
PROCEDURE GetPar* (IN key: ARRAY OF CHAR; index: INTEGER; OUT val: ARRAY OF CHAR; OUT res: INTEGER)

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

В виде костыля эта схема уже работает. Из HostFiles GetName торчит, которое используется в виндовом HostRegistry для разбора комсторки.

Логичное место для такого "ББ-го интерфейса" - не в HostFiles; HostFiles вообще не объявляет интерфейсов, а реализует их.

А что если ввести модуль (System)Host, в который собрать Host-специфичные утилиты и интерфейсы? Он будет непереносимым, его интерфейс тоже непереносимым, и рассчитан на компоновку в исполняемый файл. Туда же можно переместить argc И argv из Kernel; а может быть и ConsHook из dev18/Kernel. Так можно очистить ядро от всего, что относится не к языку, а (только) к хост-системе, и в то же время предоставить общие механизмы и реализации для Host-модулей. И GetName, который "торчит" из HostFiles, туда же переместить.

Собсно это похоже на HostConf, который Евгений предлагает, только название и предназначение шире: собрать общие Host-механизмы и утилиты.

Думаю, что механизмы Host должны быть в Host.

Давайте сделаем модуль Env с интерфейсами и модуль HostEnv с реализацией.
Ну и что, что модули не большие... и не беда, что список для линкера вырастает



для Windows

Иван, плюсую

Я предлагал сделать только модуль HostEnv для упрощения в Host-части. Интерфейс HostEnv никого ни к чему не обязывает, потому что это Host. Его можно менять, он может быть даже разным для разных Host.
Вы предлагаете пойти дальше и обобщить до Env. Т.е. поднять все это дело сразу до прикладного уровня.

Что-то от этого уже есть в Dialog, поддерживать по-хорошему надо. Будет отчасти дублирование функциональности. Хотелось бы услышать, что остальные на этот счет думают.

Например, как вариант, можно вполне себе поставить интерфес для прикладного чтения параметров в Dialog.
А HostFiles ничто не мешает напрямую в реализацию HostEnv обращаться.

Кмк, в ББ два уровня публичности интерфейсов: публичные, которые ОБЯЗАТЕЛЬНО поддерживать; и used internally. В ББ то, что used internally, не документировали; мне кажется, это несправедливо и тормозит развитие среды, поскольку этими интерфейсами пользуются системщики. Мне приходилось угадывать значение интерфейсов Windows, когда я в 2007 работал над AMisc. Полагаю, вполне можно документировать то, что used internally, однако напоминать везде, что used internally - subject to change without notice: типа, пользуйтесь, если надо, но еси чо тут все может поменяться в любой версии.

Так вот Env можно сделать used internally, поскольку он для системщиков.

А, как вы справедливо совершенно заметили, для прикладного уровня есть интерфейс в Dialog, который нужно поддерживать. Он кста реализован в (Win)HostMenus (а в Линукс - нет, увы, а неплохо бы), хотя к меню не имеет прямого отношения. Вот можно как раз навести порядок: убрать это из HostMenus и грамотно распределить между Dialog и Env/HostEnv.

Если прикладной уровень поставить в Dialog, то придется делать импорт HostEnv, а это запрещено.
Можно было бы сделать интерфейс для чтения параметров в ядре, но как обсуждали, не всегда в проектах используется ядро.
Так что вот приходим к необходимости модуля Env, и так как он уже используется в HostFiles активно, то он идет перед ним в списке линковки ядра.

Еще хочу сказать, что расширение возможностей общения ББ с внешним миром, — вполне продуманный шаг.
Надо не только читать параметры окружения, параметры командной строки. Но добавить в интерфейс возможность устанавливать некоторые параметры окружения.
Чтобы программы, которые запускаются через Dialog.RunExternal могли их использовать.

Вот тут есть интересное интервью Вирта, вспомнилось сейчас к теме.
https://www.youtube.com/watch?v=xCA5d87DtB0
https://www.youtube.com/watch?v=Cck53cQgFQg
https://www.youtube.com/watch?v=wrGytM2YTQY

И вот тут он говорит, что проблемы современных программистов в необходимости использовании многих существующих инструментов.
https://youtu.be/wrGytM2YTQY?t=410

Так то это и без Вирта понятно, но раз Вирт стоял у истоков Блэкбокса так или иначе, то приятно, что и он видит мир достаточно прозрачно, чтобы бы не говорили скептики и злопыхатели, паскалененавистники

Так что надо понемногу, не усложняя, упрощать взаимодействие с внешним миром в ББ тоже.

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

И что получится? Часть взаимодействия с внешним миром в Dialog, а часть в Env? Надо, на мой взгляд, как-то определятся -- либо в Dialog, либо отдельно.

Но это уже выходит за рамки предложенной мной темы. Почему бы не сделать поэтапно?

1) Сначала выделить работу с параметрами в нескольких вариантах Host. Это сейчас получается единообразно. И это уже можно сделать без заморочек о том, каков будет прикладной интерфейс.
2) Вопрос взаимодействия с внешним миром проработать отдельно.

Да, согласен. Давайте пока сделаем HostEnv. Проверим как он применяться будет на уровне Host, а потом уже обсудим куда на прикладной уровень его вынести.

Не нужен никакой Env. Чтобы в каркас что-то вставлять, нужны веские основания, а не просто "а давайте вставим". Вот Host привести в приличный вид надо давно, да.

Борис, у тебя не верное впечатление. Проблема чтения параметров уже существует больше пяти лет, да вообще с момента работы на Linux версией. Мы её периодически с Александром обсуждали. Но не могли ничего сделать особо из-за заботы о ненарушении совместимости. Это очень серьезная проблема, которая мешает унифицировать Host часть каркаса.

В Windows конфигурации ББ передаются как параметры командной строки. Также есть при этом и переменные окружения.
В Linux также есть аргументы командной строки. И также есть переменные окружения.

При этом для Linux/FreeBSD/OpenBSD приняли решение использовать именно переменные окружения как конфигуратор запуска.
А в Windows остается как было через параметры командной строки.

В общем это жесть, и надо как-то единообразно обращаться к переменным окружения и тем и другим через "единое окно".

Через командную строку.
У меня не может быть неверного представления, я всё время с приложениями работаю, которые под Linux и без всякого гуя (серверные). Так что тупо практика. Переменные окружения при запуске лично меня вымораживают.

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

Когда-то тоже скептически относился к параметрам через переменные окружения, но потом понял, что так совершенно удобно через sh скрипт запускать приложения в Linux. С удивлением обнаружил, что многие программы именно так и запускаются. Даже как-то лучше стал понимать мир линукса.

Тем не менее, через переменные окружения лучше не делать.

1. При передаче через аргументы программа может проверить правильность имена ключей, через переменные окружения - нет
2. С переменными окружения возможно неявное проникновение нежелательных параметров
3. Возможно, что-то ещё

Вообще, мир GNU/Linux ужасен, хотя и во многих случаях это и лучшее, что есть по совокупности качеств.