Этот участок кода вообще не нужен. Это и есть подводный камень. Ведь если включен session.auto_start или что-нибудь другое стартует сессию, то мы можем очень долго отлаживать свой код, который может оказаться вообще ни при делах.
Короче, старт сессии, по моему мнению, должен выглядеть примерно так:
function startSession() {
// установка параметров сессии
if (!session_start())
throw new Exception('Сессия не может быть запущена (либо сервер гонит, либо что-то не так с кодом)');
}
… вместо того, чтобы строить здесь полноценное тестовое приложение с… исчерпывающей обработкой ошибок ...
В данном случае функция старта сессии может вернуть только два результата. И только false означает ошибку (всего одну). И да, я считаю, что нужно написать «надо бросить исключение, записать в лог, сообщить об ошибке пользователю и т.п.» вместо «отобразить в браузере форму входа» словно ничего особенного не произошло. Коротко, ясно и ничего «такого» расписывать не надо.
Противоречие в том, что в функции под названием startSession код, который действительно стартует сессию(включая задание параметров), занимает маааленькую часть этой функции. А остальное вообще к старту сессии отношения не имеет. И возвращает не то, что сессия не стартовала, а то, что сессия истекла.
"… при истекшей сессии выкидывать пользователя из приложения на форму входа." Простите, а Вы показываете форму входа только тем, у которого время сессии истекло или всем, у кого в сессии не отмечено, что он вошёл? Зачем отдельная обработка тех у кого сессия кончилась? Ведь после окончания времени сессии пользователь должен считаться как новый и для него сайт должен выглядеть так же как и для любого другого нового пользователя сайта. А Вы поделили пользователей не на две, а на три группы: пользователь без сессии(первый раз открыл сайт), пользователь с сессией(уже листает сайт), пользователь, у которого сессия истекла. Или вы именно такого поведения добивались?
Перед первым примечанием идёт код, который не связан с истечением сессии. Если сессия не стартанула, то нужно звонить, пищать и всячески махать флагами в сторону поддержки, а не просто «отобразить в браузере форму входа».
Так же получается противоречие между названиями функции, тем что она делает.
И зачем при истекшей сессии возвращать false, ведь можно просто начать новую сессию и тогда не нужно будет заниматься дополнительной обработкой вообще?
2. Если что-то хочется поэкранировать в запросах, то нужно писать про использования переменных для метаданных (хотя тут лучше применять белые списки). Или взять какую-нибудь актуальную библиотеку, в которой нет подготовленных выражений. SQLite, например (Да и то, можно пользоваться SQLite через PDO, в котором эмулируются подготовленные выражения).
> tokenizer-либу
Она использует лексичекий парсер самого языка. Поэтому, чтобы токенайзер смог разбирать аннотации, аннотации должны стать частью языка.
> Может расскажешь это wiki.php.net/rfc/annotations?
А чего говорить то? Это предложение(не единственное) о добавление парсинга аннотаций… в отражениях(т.е. никак не влияет на работу токенайзера). Только уже существуют библиотеки по парсингу аннотаций. Не думаю, что реализация этих библиотек как-то поможет развитию самого языка.
> Или еще худший костыль встречается — чтобы tokenizer понял код, давайте его сначала делать валидным! Вот вас в ту степь понесло, хоть и не так глубоко как некоторых.
У вас «костный язык» — не ясно что именно Вы хотели сказать. Покажите на примерах то, что вы хотите от него и с чем он не справляется.
> наглухо затыкается при встрече чего-то не слишком валидного
Эм… код либо валидный, либо нет. Если парсер работает не так как хочется на невалидном коде, то я даже не знаю к кому претензии предъявлять.
> или смешанного с НЕ-php.
О чём именно речь?
> Поэтому например Doctrine до сих пор использует парсер аннотаций на регулярках…
«Поэтому»? Для языка эти аннотации это всего лишь комментарии.
> А вообще я целиком ЗА дальнейшего развития встроенного парсера.
В какую сторону?
О том что вопрос не так прост косвенно говорит размер репутации спрашивающего. Размер репутации ответившего и тот факт, что это один из разработчиков PHP.
А вопрос действительно не так прост(как и ответы). Документация не даёт полной картины всего и в ней не учитываются некоторые тонкости. Поэтому и был задан этот вопрос, поэтому и был получены эти ответы. И теперь вы сможете найти ответ на этот вопрос в поисковике, а не проводить собственные исследования, которые займут несколько часов (об этом говорит история правок ответов).
Я всё понимаю(почти) и всё уже нашёл. Просто, я не понимаю почему статья о Judy массивах не содержит примера кода использования Judy массива. При этом содержит пример использования нативного массива.
Требовательность к доводам должна на практике иметь
степени. Иначе мы впадаем в ошибку “чрезмерного сомнения” или “чрезмерной точности”, которой
соответствует и свой особый софизм. Если начать исследовать достоверность всякого довода и при
всех обстоятельствах с абсолютной точностью, то не был бы возможен обычный спор, не возможна
была бы практическая деятельность. Оставалось бы повторять мудрость древних философов-
скептиков, которые считали необходимым прилагать мерку абсолютной достоверности и поэтому во
всем сомневаться. Вот образец такого сомнения (в изображении Мольера):
Марфурий: Что вам угодно, господин Сганарель?
Сганарель: Господин доктор, я желал бы посоветоваться с вами по поводу одного обстоятельства и
нарочно сюда за тем пришел.
Марфурий: Прежде всего, г. Сганарель, прошу вас, измените вашу манеру выражаться. Наша
философия требует, чтобы не было высказываемо вполне решительных предложений, чтобы обо всем
говорилось неопределенно и чтобы суждения были условные, предположительные. И вследствие
этого вы не должны говорить: Я пришел, а мне кажется, что я пришел.
Этот участок кода вообще не нужен. Это и есть подводный камень. Ведь если включен session.auto_start или что-нибудь другое стартует сессию, то мы можем очень долго отлаживать свой код, который может оказаться вообще ни при делах.
Короче, старт сессии, по моему мнению, должен выглядеть примерно так:
В данном случае функция старта сессии может вернуть только два результата. И только false означает ошибку (всего одну). И да, я считаю, что нужно написать «надо бросить исключение, записать в лог, сообщить об ошибке пользователю и т.п.» вместо «отобразить в браузере форму входа» словно ничего особенного не произошло. Коротко, ясно и ничего «такого» расписывать не надо.
Противоречие в том, что в функции под названием startSession код, который действительно стартует сессию(включая задание параметров), занимает маааленькую часть этой функции. А остальное вообще к старту сессии отношения не имеет. И возвращает не то, что сессия не стартовала, а то, что сессия истекла.
"… при истекшей сессии выкидывать пользователя из приложения на форму входа." Простите, а Вы показываете форму входа только тем, у которого время сессии истекло или всем, у кого в сессии не отмечено, что он вошёл? Зачем отдельная обработка тех у кого сессия кончилась? Ведь после окончания времени сессии пользователь должен считаться как новый и для него сайт должен выглядеть так же как и для любого другого нового пользователя сайта. А Вы поделили пользователей не на две, а на три группы: пользователь без сессии(первый раз открыл сайт), пользователь с сессией(уже листает сайт), пользователь, у которого сессия истекла. Или вы именно такого поведения добивались?
Так же получается противоречие между названиями функции, тем что она делает.
И зачем при истекшей сессии возвращать false, ведь можно просто начать новую сессию и тогда не нужно будет заниматься дополнительной обработкой вообще?
2. Если что-то хочется поэкранировать в запросах, то нужно писать про использования переменных для метаданных (хотя тут лучше применять белые списки). Или взять какую-нибудь актуальную библиотеку, в которой нет подготовленных выражений. SQLite, например (Да и то, можно пользоваться SQLite через PDO, в котором эмулируются подготовленные выражения).
и
Такая кука не удалиться во время закрытия браузера.
Она использует лексичекий парсер самого языка. Поэтому, чтобы токенайзер смог разбирать аннотации, аннотации должны стать частью языка.
> Может расскажешь это wiki.php.net/rfc/annotations?
А чего говорить то? Это предложение(не единственное) о добавление парсинга аннотаций… в отражениях(т.е. никак не влияет на работу токенайзера). Только уже существуют библиотеки по парсингу аннотаций. Не думаю, что реализация этих библиотек как-то поможет развитию самого языка.
> Или еще худший костыль встречается — чтобы tokenizer понял код, давайте его сначала делать валидным! Вот вас в ту степь понесло, хоть и не так глубоко как некоторых.
У вас «костный язык» — не ясно что именно Вы хотели сказать. Покажите на примерах то, что вы хотите от него и с чем он не справляется.
Эм… код либо валидный, либо нет. Если парсер работает не так как хочется на невалидном коде, то я даже не знаю к кому претензии предъявлять.
> или смешанного с НЕ-php.
О чём именно речь?
> Поэтому например Doctrine до сих пор использует парсер аннотаций на регулярках…
«Поэтому»? Для языка эти аннотации это всего лишь комментарии.
> А вообще я целиком ЗА дальнейшего развития встроенного парсера.
В какую сторону?
Это что значит?
А вопрос действительно не так прост(как и ответы). Документация не даёт полной картины всего и в ней не учитываются некоторые тонкости. Поэтому и был задан этот вопрос, поэтому и был получены эти ответы. И теперь вы сможете найти ответ на этот вопрос в поисковике, а не проводить собственные исследования, которые займут несколько часов (об этом говорит история правок ответов).