![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Строго типизированный лог
А вот интересно, возможна ли такая концепция: писать не текстовый лог, а строго типизированный, чтобы в будущем можно было грузить сохраненные в него объекты и выполнять над ними какие-нибудь запросы?
Сейчас анализ логов сводится к grep, awk и прочей тексто-ориентированной линуксятине. Существует мнение, что это (текстово-ориентированный обмен данными между линуксовыми утилитами через |) хорошо, но у меня это усиленно ассоциируется с электронным прибором, у которого все платы соединены одинаковыми никак не различимыми разъемами, а плата сама решает, "что делать с входным сигналом", т.е. нет никакой защиты от обобщенного индуса-дяди-Васи-телемастера-из-соседнего-гаража.
Плохо то, что большинство интересующих объектов обычно содержат кучу пропертей-ссылок на всякие дебри, которые вне рабочего контекста смысла не имеют, а чтобы их исключить, нужно какой-то флаг на проперть типа атрибута/аннотации "NotLoggable". А это плохо тем, что логгинг не должен требовать лишнего от объектов, с которыми он работает.
Сейчас вывод в лог выглядит следующим образом:
А желательно было бы так:
А DebugAll был бы хитрым метапрограммным макросом, который бы доставал, в зависимости от флагов, имя метода, this, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.
Сейчас анализ логов сводится к grep, awk и прочей тексто-ориентированной линуксятине. Существует мнение, что это (текстово-ориентированный обмен данными между линуксовыми утилитами через |) хорошо, но у меня это усиленно ассоциируется с электронным прибором, у которого все платы соединены одинаковыми никак не различимыми разъемами, а плата сама решает, "что делать с входным сигналом", т.е. нет никакой защиты от обобщенного индуса-дяди-Васи-телемастера-из-соседнего-гаража.
Плохо то, что большинство интересующих объектов обычно содержат кучу пропертей-ссылок на всякие дебри, которые вне рабочего контекста смысла не имеют, а чтобы их исключить, нужно какой-то флаг на проперть типа атрибута/аннотации "NotLoggable". А это плохо тем, что логгинг не должен требовать лишнего от объектов, с которыми он работает.
Сейчас вывод в лог выглядит следующим образом:
mLog.DebugFormat("OnAuthenticateRequest: {0} {1} {2}",
httpApplication.Request.RawUrl,
httpApplication.Request.UserAgent,
httpApplication.Request.UserHostAddress);
А желательно было бы так:
mLog.Debug("some_user_comment",LogFlags.LocalVars | LogFlags.MethodName | LogFlags.This | LogFlags.Parameters);
А DebugAll был бы хитрым метапрограммным макросом, который бы доставал, в зависимости от флагов, имя метода, this, все локальные переменные и параметрами с именами и значениями, сериализовал бы это дело во что-то машинно-читабельное и писал бы в лог.
no subject
no subject
Плюс, конечно, проблемы императивных языков - бесконечные неконтролируемые сайд-эффекты.
Плюс проблемы низкоуровневых языков - арифметика указателей (когда она нафиг не нужна) и пр.
Плюс проблемы ссылок - когда функция изменяет свой параметр, а в синтаксисе вызова это не отражается (вообще звиздец).
no subject
no subject
2) Для того, чтобы предъявить аналог, я должен вообще хоть немного работать в данной области.
3) Может быть, вы мне покажете аналог, скажем, STM на C++?
no subject
3)Ну, fmap, например, пишется. Монады, пожалуй, тоже. STM... Пожалуй, я знаю как его написать, но сам заниматься не буду.
no subject
C++, к сожалению, слишком низкоуровневый.
> STM... Пожалуй, я знаю как его написать, но сам заниматься не буду.
Ну-ну. Только попрошу учесть, что для реализации STM необходимо гарантировать, что между операциями чтения/записи в одной транзакции не должно быть никаких сайд-эффектов вообще. Иначе это не STM, а помойка. А такие гарантии в плюсах, увы, невозможны.
no subject
То-то дептайпы в хаскеле только делают... Вот когда доделают, тогда можно будет так говорить. А пока - у кого-то слишком кривые руки.
>>А такие гарантии в плюсах, увы, невозможны.
unsafePerformIO
no subject
А в C++ они, типа, уже есть? Ну-ну.
> unsafePerformIO
За импорт System.IO.Unsafe бьют по рукам. Вы можете предъявить столь же простой критерий необходимости бить по рукам в плюсах?
no subject
>А в C++ они, типа, уже есть? Ну-ну.
в плюсах есть кривое, но всё же стандартизованное метапрограммирование на шаблонах. В ФП его аналогом будут дептайпы.
>> unsafePerformIO
>За импорт System.IO.Unsafe бьют по рукам.
Гм. Речь шла о гарантиях.
no subject
В ФП есть кривоватое, но, всё же, более прямое метапрограммирование. Дептайпы - несколько из другой оперы.
> Гм. Речь шла о гарантиях.
Именно. ЕДИНСТВЕННОЕ, что нужно сделать для получения ГАРАНТИЙ - запретить импорт System.IO.Unsafe. В плюсах получить гарантии невозможно вообще.
no subject
TH? Удачи...
>>ЕДИНСТВЕННОЕ, что нужно сделать для получения ГАРАНТИЙ - запретить импорт System.IO.Unsafe....
И половины хакаджа. Удачи...
no subject
Пользовал. Кривовато, да. Примерно как плюсовые темплейты.
> И половины хакаджа. Удачи...
Брехня. Нормальные модули если и импортируют Unsafe, то не переэкспортируют его.
no subject
Они могут пользовать его внутри себя. Удачи.
no subject
...для реализации чисто функционального интерфейса. В противном случае мы имеем баг в библиотеке, и от неё действительно нужно отказаться.