Кирилл Несмеянов

Это именно та причина, по которой двойные кавычки использовать не стоит, нарваться можно и не на такие грабли, а потом 1000 лет отлаживать. Надеюсь, что этот опыт послужит вам хорошим уроком и в будущем позволит избежать подобных проблем. А заодно научит использовать IDE, где есть статический анализ и нормальная подсветка ;)



P.S. Ну и конечно стоит читать документацию: php.net/manual/ru/language.types.string.php

\[0-7]{1,3} последовательность символов, соответствующая регулярному выражению символа в восьмеричной системе счисления, который молча переполняется, чтобы поместиться в байт (т.е. "\400" === "\000")

Вопроса нихрена не понял, но в коде есть ошибки, обуславливающиеся малым опытом:
1) По теме: "define('DIR_TMPL', __DIR__ . '/tmpl');" избавит от указаний полного пути.

Прочее:
2) Глобальные штуки - это всегда плохо. Константы достаточно заменить на файлы конфигураций, а ещё лучше класс, который умеет читать эти файлы:

<?php
// config/example.php
return [
    'templates' => __DIR__ . '/tmpl'
];

$config = new Config(__DIR__ . '/config');
$config->get('example.templates'); // ".../tmpl"

В дальнейшем это позволит расширять и модифицировать конфиги за счёт переменных окружения, т.к. реальный способ чтения конфигов скрыт за соответствующим классом.

Помимо ответов выше, стоит почитать документацию: php.net/manual/ru/function.file-exists.php

file_exists - это проверка директории или файла. А записать в папку данные невозможно. Если в "$log_file" будет путь к папке - будет ошибка.

Массивы, строки, коллекции: https://github.com/illuminate/support
Каррирование и частичное применение: https://github.com/SerafimArts/Curry

Стоит разделять публичные и приватные исключения. Пользователям не стоит видеть внутреннюю кухню. Так что:

class HttpExcepton extends RuntimeException {}
class ExampleHttpException extends HttpExcepton {}

//

throw new ExampleHttpException('Сообщение не может быть пустым', 422);

Так что всё это дело можно свести к одному единственному try/catch, который будет выводить текст из всех HttpExcepton (и статус код, например, в данном примере 422), и выводить сообщения "Internal Server Error" от любых других.

Скачать php с офф сайта и в консоли проекта набрать php app/console server

У каждой функции в PHP есть два контекста: Статический и объекта. Метод - это обычная именованная функция, у которой заранее объявлены оба этих контекста. Таким образом мы получаем, что метод один и выделение памяти под него тоже одно, но для разных объектов меняется контекст (т.е. ссылка на this), а значит создание нового объекта - это всего лишь выделение this контекста для метода, т.е. тупо один адрес.

Помимо этого, создавая новый объект память не выделяется вообще. Если объект идентичен предыдущему, то адрес нового объекта соответствует предыдущему с пометкой разделения ZVAL-структуры при мутациях (до некоторого времени даже баг был, когда функция spl_object_hash возвращала одну и ту же строчку для двух разных объектов, которые содержали одни и теже данные). Во время изменений объектов - ссылка на изменённое поле разделяется и новое значение пытается занять память тех переменных (напоминаю, что структура ZVAL едина для всех типов переменных), которые были помечены для уничтожения через GC (т.е. refcount=0), это позволяет избавиться от лишних аллокаций памяти. Такая модель поведения, например, позволяет делать клонирование (оператор clone) и инстанциирование (оператор new) объектов без выделений памяти вообще.

P.S. Так было в какой-то из 5.х веток, когда я исследовал поведение пыха. Сейчас же, когда на носу 7.3 - я уже хз, много поменяли, хотя в основном работа была проведена по уменьшению потребления памяти zval объектами, DCE оптимизациям и AVX/SSE инструкциям, так что не думаю что сильно.

Ураааа, новая классическая дырища в сайте!

Вы ведь понимаете, что благодаря этому коду, после того как он заработает - вас сможет взломать любой школьник?

Правильно ли я понимаю, что т.к. PHP не асинхронный язык,

Нет, не правильно.

то если пользователь 1 отправил запрос (например он будет выполняться 10 секунд), а через 2 секунды пользователь 2 отправит тоже запрос, то он обработается только тогда, когда запрос от 1 юзера будет готов?

Зависит от реализации и наличии блокирующих операций.

Стоит заметить, что не важно синхронные операции или нет - сумма общего выполнения запросов будет идентичной (хотя в случае асинхронной работы даже дольше, т.к. издержки на переключение контекстов).

Есть некая реализация вебсокетов на php (реализовано на основе этого).

Феерический трешак. Ни тестов, ничего. Да и в коде глобалсы. Жесть

Хотите практики - запилите бложик себе. Самое популярное занятие в '18ом году после туду листов

mockery?

Немного о наболевшем:

В MVC нет экшенов. MVC работает следующим образом:
- Во вьюхе располагается модель (например "текстовое поле")
- Любые изменения в модели сразу же изменяют вью (изменяем текст в текстовом поле и этот текст визуализируется/рендерится)
- Контроллер подписывается на события вьюхи (например "изменение текста в текстовом поле") и выполняет какое-либо действие, в том числе изменяет модели (ну хз, например проверяет что длина не более 10 символов. Или другой пример. Контроллер подписывается на событие нажатия кнопки "delete" и удаляет текст из модели текстового поля, а модель сразу же перерисовывается, т.к. напрямую связана с представлением).



Всё это прекрасно видно на картинке, которая взята с вики: https://ru.wikipedia.org/wiki/Model-View-Controller

В вебе реализация MVC без сокетов не возможна физически (который, к слову, в районе 80х-90х годов назывался MVCE: Model-View-Controller-Editor, не суть). Большинство существующих решений - это вариации MVP (Laravel/Symfony/etc) с небольшими нюансами. Контроллер там называются контроллерами, а не презентером по принципу GRASP и никак не связан с MVC.

НО. Есть такая штука как коллективное мнение. Например, по правилам русского языка можно писать "парашут", а не "парашют" начиная с какого-то там 2010го года. Это теперь норма. Хз. Короче безграмотных неучей дохрена. И т.к. таких реально дохрена, кто не может отличить одно от другого и не быть неучем, то решили что назовём-ка мы это дело "MVC с пассивными моделями", потому что называть этот подход MVP слишком сложно, это же читать надо ещё, учиться, лучше будем терминами кидаться, подумают что умный.

Так вот, к чему я веду. Классический MVP в вебе неудобен (что можно увидеть на примерах первого Zend, Phalcon и прочих догматов), по-этому добавили прослойку в виде роутера, который говорит: "По адресу /users при GET запросе отправляйся мне вот в этот класс и выполни вот этот метод", например: "$router->get('/users', 'UserClass', 'action')". Сам метод, возвращает нужную вьюшку с данными и называется "экшен", а класс, который содержит набор этих самых "экшенов" называется "контроллер" или "презентер". Во вьюшке, с помощью читов (шаблонизатора) можно указать, например, какой хедер\футер (лайаут) использовать, какой тайтл и прочее. Таким образом мы получаем разные страницы по разным адресам с разными данными, с возможностью сохранить основное оформление и пересипользовать какие-то другие куски вьюшек.

\base64_encode(\random_bytes(...));
Не проще ли?

Два варианта выше вполне годятся. Ну или написать свою EBNF грамматику, воспользовавшись:
1) Hoa LL(1)/LL(k): https://github.com/hoaproject/Compiler (Пример выше nikic от Mikhail Osher использует LALR парсер на основе Yacc)
2) Или моим форком: https://github.com/railt/compiler (возможности грамматики почти те же, но исправлено несколько ошибок, переписаны исходники и ускорен лексический анализ в 140 раз).

Эм, а может всё же не парить мозг и использовать JSON тип? Там и индексация, как бы есть, да и тип нативный...