Pull to refresh
2
0
Игорь Харченко @the_kane_is_alive

Погромист, строитель светлого будущего >_<

Send message

На самом деле есть ещё одно несказанное использование static, доступное по умолчанию с PHP 5.4:


class A
{
    private $item;

    public function foo()
    {
        // здесь колбэк по умолчанию замыкается на this контекста, 
        // с которого он был вызван (по умолчанию с PHP 5.4)
        $callable = function () {
            return $this->item * 2;
        }
    }

    public function bar()
    {
        // однако если указать static, то замыкаться на this вызванного контекста 
        // колбэк уже не будет
        $callable = static function () {
            return $this->item * 2; // кинет fatal error
        }
    }
}
Исправил.
Надо было конечно сразу исправить, но лучше поздно, чем никогда)
Подводя итог, скажу, что целью статьи было вовсе не создание системы логов как таковой, а в первую очередь донесение до читателя той мысли, что не всегда ставить селективный атрибут влево – это хорошо.
Логи выступали лишь в качестве примера, и судя по комментариям, пример получился неудачный. Но на данный момент ничего лучше в голову не приходит
и вообще, логи модифицировать никто не должен.

Под модификацией данных я имел ввиду не update/delete, а insert конечно же. Свой старый комментарий изменить не могу
В данной задаче можно, но здесь суть задачи заключается именно в хранении логов в таблице, а не в переносе их в другое место
Если будет два индекса на разные колонки, тогда модификация данных будет хуже выполняться
Дык это и статья не для седьмой версии, в которой всё за тебя интерпретатор провалидировал.
Поэтому про жуть и мрак в плане «к чему пользоваться старьём» – тут согласен.
Если вы что-то другое имели ввиду — то распишите подробнее.
С чего вы взяли вообще что конечный слэш является частью пути? Где, в какой спецификации, в какой файловой системе это так?

Это просто пример. Можно его сколь угодно доводить до идеального состояния, но конечной целью было не создать целое приложение, а протестировать работоспособность одного трейта на примере пары классов.
Почему вдруг для трейтов нужна отдельная папка, а для неких «моделей» — другая? Откуда берется такая структура?

Можно запихнуть всё и в одну папку models, нет никаких проблем)
Расскажите — чем лучше «хостинг»?

Согласен, ничем.
(Если не считать того, что всё за тебя уже настроено заранее)
Ну раз уж очень хочется, то хорошо, можно и так написать:
$separator = DIRECTORY_SEPARATOR;
$basePath = __DIR__ . $sep;

$traitsFolderName = 'traits';
include_once($basePath . $traitsFolderName . $separator . 'Validator.php');

$modelsFolderName = 'models';
include_once($basePath . $modelsFolderName . $separator . 'Pen.php');
include_once($basePath . $modelsFolderName . $separator . 'Notebook.php');

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

Это в трейте и реализовано.

И при чем тут принципы полиморфизма?

Да, про полиморфизм я не к месту написал, признаю.

Ну и лучше все же на 7 переходить. А то тут просится картинка с буханкой-троллейбусом.

Многие хостинг-провайдеры до сих пор остались в прошлом веке со старыми версиями.
Искренне не понял, причем тут слово «Полиморфизм». Возможно вы имели в виду что-то другое? Например «тайп-хинтинг»?

Да. Всё же я имел ввиду определение типов.
А под словом «полиморфизм» здесь предполагалось то, что один и тот же трейт можно использовать во всех классах, к которому трейт присоединён.
Поправлюсь в терминологии.

P.S. За вот такое:
include_once("{$dir}{$sep}traits{$sep}Validator.php");

я обычно увольняю…

Просто дурная привычка пилить всё на скорую руку.
Добавил в статью автозагрузку классов вместо include-ов.

Information

Rating
Does not participate
Location
Томск, Томская обл., Россия
Registered
Activity