> -- Евгений Темиргалеев писал(а):
> Теперь слово предоставляется Александру - пусть пояснит, что он имел ввиду.  :)Я, в общем-то, имел в виду то, что написал. Если интересует мой вариант обоснования, то оно у меня таково. Если нужно платформенно-зависимое решение (а пути в Windows отличаются от путей в Linux, например), то лучше импортировать HostFiles, подчеркнув эту зависимость. В этом случае правится только один модуль (HostFiles), а не два (Files и HostFiles), так что необходимые изменения лучше локализованы. Если волнует совместимость с другими дистрибутивами ББ (что довольно редкий случай само по себе), то ещё возможен вариант создания собственного драйвера, например, с именем PrivHostFiles, и последующее прямое использование этого модуля при проверке типа: WITH loc: PrivHostFiles.Locator DO... Реализацию PrivHostFiles можно получить копированием HostFiles в подсистему Priv (имя Priv зарезервировано для частного использования, поэтому не может конфликтовать с другими подсистемами ББ) и добавлением нужных функций, либо публикацией нужных полей, если они уже там есть.

Насчёт того, что идея рубится на корню, то тут трудно что-то сказать однозначно. Например, почему нет такой функции в Files как "вернуть путь в виде строки"? Потому, что Files независим от платформы, а строка имеет зависимый формат. С другой стороны, модуль Files готов принимать строки в платформенно-зависимом формате и на их основе делать Locator'ы, например. Получается асимметрия интерфейса. Для этого есть особая причина (не вижу) или это упущение дизайнера модуля?

Абстрактный модуль, насколько я понимаю, должен предоставлять интерфейс, который является общим для всех платформ. При этом неизбежно и необходимо что-то упустить из виду (например, тот факт, что для каждого диска Windows помнит "текущий каталог", в который мы попадаем, набрав в командной строке только имя диска c: или d: - в Linux, где единая файловая система данный концепт просто не имеет смысла, так как там нет дисков, а есть единое дерево каталогов и устройств с общим корнем). Расширять абстрактный модуль вряд ли имеет смысл без тщательно продуманного обоснования, тем более если наша цель - получить платформенно-зависимую информацию. В данной конкретной задаче проблема в том, что фремворк ББ редиректом /USE спрятал от нас знание о пути к BlackBox.exe, которое тем не менее, может пригодиться в каких-то задачах. Выхода два - либо поправить фреймворк, либо обратиться к средствам платформы (например, узнать путь к исполнимому модулю по хэндлу текущего процесса). Первое ведёт к несовместимости вашей подсистемы с другими ББ, второе ведёт к несовместимости с другими платформами. Смотрите, что вам важнее. Многое зависит от конкретной задачи - например, от того, планируется ли распостранять результат в виде подсистемы под разные ББ, или как скомпонованное приложение в виде exe-модуля. Не зная всей полноты условий, я могу только поделиться общими соображениями, что и сделал в данном посте. Спасибо за внимание.