В аргументах, как и в массивах, завершающая запятая ставится только в случае, если терминалы лексемы находится на отдельных от элемента строках.
Это позволяет не добавлять запятую при дублировании строки и, как следствие, не учитывать добавленную запятую в системах версионирования. Сравним два диффа
Что не так с требованиями бизнеса не проводить операцию при невозможности записать логи?
С требованием бизнеса всё норм. Только вот это уже не логгер. Потому что логгер не про бизнес вообще.
Я попробую метафорой.
Атомарное действие в php (будь то HTTP запрос или какая-консольная команда, если она не демон). Это как поезд который идет из точки А в точку Б.
Логгер — это как самописец в поезде. Вы же не станете жать экстренное торможение, только потому что самописец отказал? Вы даже не можете знать, что он отказал.
То, о чем вы говорите — это контрольно-пропускной пункт в котором поезд останавливается для оформления документов, регистрации груза и т.п. Поезд не пойдет дальше, пока все документы не будут оформлены.
То что вы пытаетесь использовать самописец, для операций требующих подтверждения записи — это ошибка. Ведь чтобы убедиться в том что самописец записал данные — вам нужно его открыть ключом или сломать. Для проверки работоспособности самописцев — есть депо обслуживания.
Возвращаясь к миру PHP: Вы пытаетесь реализовать транзакции — это хорошо. Вы не можете отличить логирование от транзакционных операций — это плохо.
Если код сложнее читать — его сложнее поддерживать. Читать его сложнее программисту, который привык писать по стандарту (с долей вероятности превышающей 50% — PSR) отличному от стандарта который вы используете.
И да, если ваш логгер бросает исключения, которые (внезапно!) должны логироваться, то честное слово — у вас проблемы побольше чем выразительность PSR. И, пожалуй, я могу понять если это легаси, с которым приходится жить. Но в новых проектах так делать нельзя.
PSR — всего лишь рекомендации — вы не обязаны их соблюдать.
GRASP — всего лишь шаблны — вы не обязаны их использовать.
SOLID — всего лишь принципы — вам не обязательно им следовать.
Подпишусь под каждым утверждением.
А еще никто вас никто и никогда не обяжет и соблюдать элементарный этикет, отказаться от подворотов в минус двадцать и использовать презервативы при случайных связях. Нет таких законов.
По результатам выборов в PHP-FIG новый core-комитет составят Korvin Szanto, Enrico Zimuel, Chris Tankersley и Massimiliano Arione с секретарём Buster Neece.
В целом согласен (плюс/минус), кроме пункта про слитую карму. Эта проблема действительно существует. Один неосторожный комментарий идущий в разрез с мнением коллективного сознания и, если верить индуистам, на следующей итерации сансары — вы (в лучшем случае) червяк.
Количество минусов зависит от степени экспрессивности комментария, угла между векторами мнений, резонансности поста, а также положения звезд на небе (но это не точно).
Да что там мелочиться. Можно, в принципе, поставить вот так: https://www.php.net/manual
И будет норм. Это не сарказм. Я вполне серьезно считаю, что надо прочитать всю доку хотя бы раз (возможно, пропуская специфичные разделы экзотических расширений).
Но фишка в том, что некоторые темы размазаны по доке. Не от плохого дизайна структуры доки, а от того, что иначе и не получится написать систематизированную документацию. Кто хоть раз писал тех.маны — прекрасно поймет о чем речь. И бывает хочется скомпилировать полученные знания в небольшой шпаргалке.
Хотя никакого оригинального исследования данный пост в себе не содержит, субъективно считаю вполне уместным делать такие заметки.
Да не, я без претензий, и плюс материалу поставил. Просто есть устоявшееся выражение "битовая маска", которое более менее описывает, что здесь происходит. Но за весь текст оно не встречается ни разу. Только это и вызвало такой диссонанс. А походу текста складывается впечатление, что это рокет-сайнс какой-то )
Плюс, не хватает немножко практического sql, сравнения непосредственно с битовой маской (если бы мы сразу хранили все значения в маске) и фильтрацией по a^b. Ну это на заметку если вы хотите следующий материал по этой же теме писать.
Вообще не понял о чем материал… для меня всё просто:
Переменная — это переменная. И не важно меняю я ее значение в коде или нет. Сейчас я не хочу её менять, а завтра захочу.
А константа — это константа. Ее значение не зависит от того, что хочу я или еще кто-то. Оно просто есть. Как те самые ПИ, постоянная Эйлера, количество дней в неделе, количество градусов полного угла, и т.д. и т.п. Константы инвариативны по определению.
В общем, я не очень понимаю откуда путаница. И я даже не встречал сторонников "const-first" ни разу. Думается мне, что это довольно занимательные зверьки.
В аргументах, как и в массивах, завершающая запятая ставится только в случае, если терминалы лексемы находится на отдельных от элемента строках.
Это позволяет не добавлять запятую при дублировании строки и, как следствие, не учитывать добавленную запятую в системах версионирования. Сравним два диффа
Учитывая, что мы просто добавили
qux, второй вариант выглядит несколько лаконичнее.Я очень плотно сижу на G-экосистеме. Даже не знаю, можно ли сейчас с неё слезть.
С требованием бизнеса всё норм. Только вот это уже не логгер. Потому что логгер не про бизнес вообще.
Я попробую метафорой.
Атомарное действие в php (будь то HTTP запрос или какая-консольная команда, если она не демон). Это как поезд который идет из точки А в точку Б.
Логгер — это как самописец в поезде. Вы же не станете жать экстренное торможение, только потому что самописец отказал? Вы даже не можете знать, что он отказал.
То, о чем вы говорите — это контрольно-пропускной пункт в котором поезд останавливается для оформления документов, регистрации груза и т.п. Поезд не пойдет дальше, пока все документы не будут оформлены.
То что вы пытаетесь использовать самописец, для операций требующих подтверждения записи — это ошибка. Ведь чтобы убедиться в том что самописец записал данные — вам нужно его открыть ключом или сломать. Для проверки работоспособности самописцев — есть депо обслуживания.
Возвращаясь к миру PHP: Вы пытаетесь реализовать транзакции — это хорошо. Вы не можете отличить логирование от транзакционных операций — это плохо.
PSR — это и есть ± общепринятый стандарт.
Если код сложнее читать — его сложнее поддерживать. Читать его сложнее программисту, который привык писать по стандарту (с долей вероятности превышающей 50% — PSR) отличному от стандарта который вы используете.
И да, если ваш логгер бросает исключения, которые (внезапно!) должны логироваться, то честное слово — у вас проблемы побольше чем выразительность PSR. И, пожалуй, я могу понять если это легаси, с которым приходится жить. Но в новых проектах так делать нельзя.
PSR — всего лишь рекомендации — вы не обязаны их соблюдать.
GRASP — всего лишь шаблны — вы не обязаны их использовать.
SOLID — всего лишь принципы — вам не обязательно им следовать.
Подпишусь под каждым утверждением.
А еще никто вас никто и никогда не обяжет и соблюдать элементарный этикет, отказаться от подворотов в минус двадцать и использовать презервативы при случайных связях. Нет таких законов.
Не завидую разрабам, которые к вам будут приходить или от вас уходить. Весь мир пишет по PSR.
Хочу пункт за голосование вниз: "дезинформация"
Кто все эти люди?
В целом согласен (плюс/минус), кроме пункта про слитую карму. Эта проблема действительно существует. Один неосторожный комментарий идущий в разрез с мнением коллективного сознания и, если верить индуистам, на следующей итерации сансары — вы (в лучшем случае) червяк.
Количество минусов зависит от степени экспрессивности комментария, угла между векторами мнений, резонансности поста, а также положения звезд на небе (но это не точно).
Я и не говорил, что она "очень". Я сказал, что проблема размазанности не от этого )
А еще:
https://www.php.net/manual/en/reflectionmethod.setaccessible.php
https://www.php.net/manual/en/function.utf8-encode
https://www.php.net/manual/en/function.urldecode
https://www.php.net/manual/en/function.get-object-vars
https://www.php.net/manual/en/class.jsonserializable
Да что там мелочиться. Можно, в принципе, поставить вот так:
https://www.php.net/manual
И будет норм. Это не сарказм. Я вполне серьезно считаю, что надо прочитать всю доку хотя бы раз (возможно, пропуская специфичные разделы экзотических расширений).
Но фишка в том, что некоторые темы размазаны по доке. Не от плохого дизайна структуры доки, а от того, что иначе и не получится написать систематизированную документацию. Кто хоть раз писал тех.маны — прекрасно поймет о чем речь. И бывает хочется скомпилировать полученные знания в небольшой шпаргалке.
Хотя никакого оригинального исследования данный пост в себе не содержит, субъективно считаю вполне уместным делать такие заметки.
Хороший материал. Добро пожаловать!
Я "подсаживался" в офис к логистам. Просто пришел и спросил можно ли у них место снять (при том, что они и сами офис снимали) — не отказали )
Отлично, ждем следующего материала.
Да не, я без претензий, и плюс материалу поставил. Просто есть устоявшееся выражение "битовая маска", которое более менее описывает, что здесь происходит. Но за весь текст оно не встречается ни разу. Только это и вызвало такой диссонанс. А походу текста складывается впечатление, что это рокет-сайнс какой-то )
Плюс, не хватает немножко практического sql, сравнения непосредственно с битовой маской (если бы мы сразу хранили все значения в маске) и фильтрацией по a^b. Ну это на заметку если вы хотите следующий материал по этой же теме писать.
Вы так круто всё это развернули. Я даже не сразу понял, что речь идет о банальной битовой маске. Ближе нужно к народу-то быть )
Автор книгу, походу тоже с телефона писал
Вообще не понял о чем материал… для меня всё просто:
Переменная — это переменная. И не важно меняю я ее значение в коде или нет. Сейчас я не хочу её менять, а завтра захочу.
А константа — это константа. Ее значение не зависит от того, что хочу я или еще кто-то. Оно просто есть. Как те самые ПИ, постоянная Эйлера, количество дней в неделе, количество градусов полного угла, и т.д. и т.п. Константы инвариативны по определению.
В общем, я не очень понимаю откуда путаница. И я даже не встречал сторонников "const-first" ни разу. Думается мне, что это довольно занимательные зверьки.
Текст вышел коротковатым, как по мне. Как будто на середине оборвался
Таки вакуум ни вытечь ни натечь по определению не может.