множество уровней сообщений. Я набрасываю сообщения в стринглист, а когда они нужны, вызываю их через функцию Text и указываю какие уровни показать.
Структура проекта примерно такая:
При запуске главной формы, создаётся ядро, ядро создаёт логгер и остальные модули.
Модули скидывают сообщения логов в ядро, ядро их кладёт в логгер, а главная форма по необходимости дёргает из него текст и показывает в мемо.
При отправке сообений лога, они помечаются одним из элементов множества
TLevel = (LUART, LCONSOLE, LUSER, LCOMMON, LERRORS, ALL);
которые описаны в модуле логгера.
И тут возникает вопрос. Получается, что не достаточно прописать всем модулям в юсес ядро (там процедура, которая перебрасывает сообщения в логгер), нужно ещё и логгер туда прописать.
Хз на сколько это правильно. Как тут лучше поступить?
Забить и прописать логгер во всех модулях, которые скидывают логи.
Вынести описание TLevel в отдельный модуль и уже его прописывать всем заинтересованным.
Вынести описание TLevel в ядро. Но тогда у ядара будет в юсесах логгер, а у логгера ядро, вроде как это не правильно.
Забить на отдельный тип данных, и передавать уровни цифрами. Ввести константы типа LUART=1 LCONSOLE=2 итд, и использовать их.
Ну для этого придумали enum, типа type TLogLevel = (llInfo, llWarn, llError etc) ну и если он у тебя в type модуля прописан, то должен везде подхватываться
напрямую модуль логгера не подключен в другие модули. Он какбы через прокладку работает. Поэтому этот тип в других модулях не виден
Вынеси tlevel в свое "ядро" а в логгере разреши циклическую ссылку на ядро в имплементации. Если уж так не хочется отдельный модуль с tlevel делать и везде его заюзывать
ай яйяй ненадо циклических ссылок на ровном месте
Чёт изврат какойт, но если что...у тебя он все равно цифры, и ты его можешь проверять как цифру
Да все можно, если осторожно.... Для того (а не для скорости компиляции, как тут некоторые спорят) и нужны uses в имплементации. Ну и...Это учебный логгер, можно делать как угодно.
Стикер
Я бы создал отдельный модуль с интерфейсом, а в ядре реализовать этот интерфейс. В других модулях подключать вместо ядра модуль с интерфейсом. TLevel можно кинуть в отдельный модуль, всем его указывать в uses если это необходимо. Не вижу тут проблемы.
Так у него есть исходники моего логгера, в которых именно так и сделано
Поскольку у тебя прокси-функция логгера уже защита в "ядро", значит у тебя ядро от логгера зависит. Почему бы просто не добавить в ядро ещё и прокси типа? Unit ядро; Interface uses логгер; Type TLevel = логгер.TLevel;
Моё сообщение было больше про организацию кода, а не про логгер. Выделение в отдельный модуль интерфейса общения с "ядром" позволит избавиться от перекрестных ссылок (а от них избавляться нужно, уж больно много гемороя они доставляют).
У меня интерфейс логгера выделен в отдельный юнит ) Так что всё верно в том сообщении )
Так можно было? 😳
А ты сделай uses windows; var r: trect; А потом ctrl-клики на trect и посмотри как оно определяется. В лазаре, кстати, есть проблемы как раз когда одни и те же майкросотовские типы снова и снова определяются в разных модуля и для компилятора это разные, несовместимые типы.
какой в этом смысл? всеравно неявная зависимость от логгера, тогда уже делать ее явной
Вообще, я же могу написать вот такие вызовы процедур? Windows.DeleteFile('1.txt'); SysUtils.DeleteFile('1.txt'); Могу. И вряд ли я сейчас кого-то удивил. А чем отличаются типы??? Там все то же самое
они несовместимые только если через type определены, иначе это тотже самый тип емнип
Нет,именно сто там копипастом снова и снова... В дельфе на трахались, вынесли в types и всех остальных через него маршрутизировали. Казалось бы хорошо известный и базовый приём. Странно...
Не знаю. Он пишет, ему виднее. Даже банальное "мне так комфортнее" например
Type TLevel = логгер.TLevel;//совместимы
Обсуждают сегодня