12.02.2017 22:30
pronskiy 62 13300 Источник

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.
Приятного чтения!

Новости и релизы


  • WordPress 4.7.2 — Обновление примечательно тем, что в нем без огласки была устранена критическая уязвимость, позволяющая удалённому атакующему без аутентификации изменить содержимое любой страницы через манипуляцию с REST API.
    Несмотря на то что уязвимости подвержены только WordPress версий 4.7.0 и 4.7.1, по интернету прокатилась волна автоматизированных атак. Взлому уже подверглись более 1,5 миллиона ресурсов.
  • PhpStorm 2017.1 EAP 171.3019 — В свежей EAP версии добавлена поддержка Codeception.
  • Go! AOP Framework 2.1.0 — В релизе поддержка PHP 7.1 и несколько новых возможностей.
  • PHPUnit 6.0.0 — Данный релиз требует PHP версии не ниже 7.0, также для большинства классов теперь используются пространства имен вместо префиксов. Полный список изменений тут. Небольшой туториал по миграции.
  • habr Релиз LiveStreet 2.0
  • habr Yii 2.0.11

PHP


  • RFC: Make Libsodium a Core Extension — Предложение включить криптографическую библиотеку Libsodium в ядро успешно прошло голосование и будет реализовано уже в PHP 7.2. Сообщество также проголосовало за использование префиксного синтаксиса sodium_* вместо пространства имен \Sodium\*. Тем не менее уже доступна обертка firehed/sodium для использования функций через пространство имен. Нельзя не отметить иронию автора.

  • RFC: Arrow Functions — Четвертая попытка добавить короткий синтаксис для анонимных функций в PHP.

    Первое предложение с конструкцией вида: $x ~> $x + $y не прошло голосование. Затем был предложен альтернативный синтаксис: function($x) => $x + $y. Дальше выносился на рассмотрение синтаксис: ^($x) => $x + $y. На этот раз предлагается использовать fn(parameter_list) => expr:

        function ($x) use ($y) {
        return $x + $y;
    }

// Эквивалентно:

    fn($x) => $x + $y

    Кстати, инструмент 3v4l.org позволяет протестировать код на RFC, для которых существует ветка с реализацией, в частности, для Arrow Functions.

Инструменты



Материалы для обучения



Занимательное



Спасибо за внимание!

Если вы заметили ошибку или неточность — сообщите, пожалуйста, в личку.
Вопросы и предложения пишите на почту или в твиттер.

Прислать ссылку
Быстрый поиск по всем дайджестам
< Предыдущий выпуск: PHP-Дайджест № 101
Поделиться с друзьями
-->

Комментарии (62)


  1. saggid
    13.02.2017 04:25
    #10066742
    -8

    Большое спасибо за дайджест)


    Сообщество также проголосовало за использование префиксного синтаксиса sodium_* вместо пространства имен \Sodium\*. Тем не менее уже доступна обертка firehed/sodium для использования функций через пространство имен.

    Кому-то жить не хочется, если он не ощущает себя важной жопой пишущим качественный ООП-код?)


    1. igordata
      13.02.2017 05:46
      #10066780
      +3

      Кому-то жить не хочется, если он не ощущает себя важной жопой пишущим качественный ООП-код?)
      Тебе просто неприятно то, что кому-то хочется иметь неймспейсы? Это плохо? Плохо выделяться из толпы или плохо быть толпой? Зачем вообще выдавать свою качественую характеристику предпочтений манеры работы других людей? Почему ты вообще это написал? Зачем ты заставил меня задавать все эти вопросы?


      1. saggid
        13.02.2017 10:36
        #10066932
        -6

        Очень много всяких вещей в программировании программисты делают без реального обоснования с точки зрения пользы для программного кода.


        Найс фингс — это ложить все функции в свои неймспейсы? Может вообще удалить функции и оставить только их ооп-вариации? Чтобы совсем как у взрослых было?


        И чем лучше от этого станет код? Тем что объектов станет больше? Тем что use-директив в начале файла добавится?


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


        Глобальные функции просты и очень удобны в использовании. Я очень рад, что они есть в php, и сам часто расширяю код проекта своими собственными функциями. Выглядит красиво, работается удобно, понимается легко. Разве не к этому надо стремиться при написании большого проекта?


        1. Fesor
          13.02.2017 11:01
          #10066976
          +5

          И чем лучше от этого станет код? Тем что объектов станет больше? Тем что use-директив в начале файла добавится?

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


          Глобальные функции просты и очень удобны в использовании.

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


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

          выглядит некрасиво. работается удобно до какого-то момента, в целом же в вашем коде просто увеличивается количество шума. И если проект большой, то это будет сильно влиять на читаемость кода, и как следствие, поддерживать такой код будет чуть-чуть да дороже.


          1. saggid
            13.02.2017 15:08
            #10067618

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


          1. saggid
            13.02.2017 15:56
            #10067762
            -2

            Приведу несколько примеров кода нашего проекта. Скажем, есть у нас модель текстовых данных одного объекта. И вот там есть вот такой метод:


            public function setDescriptionMarkdownAttribute($value)
{
    $this->attributes['description_markdown'] = $value;
    $this->attributes['description_html'] = ace_editor_parse($value);
}

            Как видим, здесь вызывается функция. Она парсит строку и возвращает нужный HTML код. Разве не просто и красиво?


            Или вот ещё пример, метод класса лекции в нашем проекте:


            public function getFirstContentLink(Course $course)
{
    return link_to_lesson($course, $this, $this->realContents->first());
}

            Как видим, тут используется функция link_to_lesson. Она генерирует ссылку на блок контента лекции определённого курса. Эта функция используется в том числе в шаблонах проекта, а также в прочих PHP классах, например в генераторе карт сайтов… В общем, одна функция — используется везде, где нужно. Разве не удобно?


            Или вот ещё один очень простой хелпер в модели пользователя, тут вообще всё просто:


            /**
 * Возвращает True в том случае, если данная модель является текущим
 * авторизованным пользователем.
 *
 * @return bool
 */
public function isCurrentUser()
{
    return ($this->id === current_user()->id);
}

            Ну и напоследок — метод в классе авторизации для создания нового пользователя для проекта, который тоже использует по большей части функции:


            protected function create(array $data)
{
    $user = User::create([
        'name'     => $data['name'],
        'email'    => $data['email'],
        'password' => bcrypt($data['password']),
    ]);

    event(new UserCreated($user));

    send_email_to_admins('У нас новый пользователь!', 'emails.user-registered', [
        'newUser' => $user,
    ]);

    // Отправим пользователю сообщение-приветствие
    send_email_to_user('welcome', $user);

    session(['first-login' => true]);

    return $user;
}


            1. gro
              13.02.2017 16:14
              #10067796
              +9

              Несомненно, все здесь присутствующие, в восторге от ваших успехов.


              1. saggid
                13.02.2017 19:13
                #10068172

                Я не имею права показать и доказать свою точку зрения на практических примерах из своего реального проекта?


                1. Fesor
                  13.02.2017 19:25
                  #10068196
                  +1

                  Вам код ревью сделать и описать проблемы?


                  1. saggid
                    13.02.2017 19:34
                    #10068206

                    Да я вроде и сам вполне нормально могу работать с проектами. И сам занимаюсь код ревью. Проблемы, что тут вы пишете — они больше из пальца высосаны, и реальной проблемы не составляют. Я это уже обсуждал в своей отдельной статье на хабре с людьми. Да, если есть желание — можете подключаться к тем обсуждениям. Только пожалуйста прочитайте сначала мои разъяснения, чтобы не проходиться повторно по одним и тем же темам.


                    1. Fesor
                      14.02.2017 00:03
                      #10068604
                      +2

                      Проблемы, что тут вы пишете — они больше из пальца высосаны

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


                      p.s. Если что меня не напрягают функции как таковые, меня напрягают event, current_user и send_email_to_user. К примеру у меня нотификации отправляются так:


                      $this->notificator(new WelcomeNotification($user));

                      Профит — легко тестировать, легко поддерживать, разделение ответственности, нет волшебных строковых констант в коде, легко рефакторить, большая часть тупых багов выявляется статическим анализом.


                      1. saggid
                        14.02.2017 01:23
                        #10068666
                        -3

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


                        И пара функций здесь вообще из ларавел взяты, они есть из коробки: event и session. Ларавел тоже вроде покрыт тестами.


                        Тупые баги тоже вроде находятся без проблем) я только не понял что за статический анализатор.


                      1. bohdan4ik
                        16.02.2017 22:56
                        #10075500

                        Узнаю laravel. Там много всяких штуковин, вроде event, session, Auth::user(), DB::table('smth')->insert(). Снаружи выглядит весьма сурово, но это всё фасады на магии __callStatic. Внутри работает service locator и dependency injection (если есть желание — можно использовать только DI, без магических геттеров).


                        event:
                        https://github.com/laravel/framework/blob/5.4/src/Illuminate/Foundation/helpers.php#L477


                        app:
                        https://github.com/laravel/framework/blob/5.4/src/Illuminate/Foundation/helpers.php#L99


                        Нотификации, путь слабых:


                        function actionRegister()
{
  ....
  event(new UserRegisteredEvent($user));
}

                        Нотификации, ваш путь (здесь могу ошибиться с выбором внедряемого класса, только начинаю осваивать laravel):


                        function actionRegister(Illuminate\Contracts\Events\Dispatcher $eventService)
{
  ...
  $eventService->dispatch(new UserRegisteredEvent($user));
}

                        P.S.: ура, markdown разметка для отхабренных! :)


                        1. saggid
                          17.02.2017 00:33
                          #10075610

                          в этом же и дело. первый вариант — не путь слабых. а самый короткий путь.


                          практической разницы вообще никакой между этими двумя вариантами


            1. ellrion
              13.02.2017 16:44
              #10067880
              +1

              собственно вы и показали что используете префиксы: ace_editor_, send_email_


              1. saggid
                13.02.2017 16:50
                #10067898

                Это не префиксы :) Префиксы тогда должны быть например так: strings_ace_editor_parse. То есть, функция из ядра проекта, отвечающая за работу со строками.


                Или education_link_to_lesson. То есть, функция из модуля интерактивных уроков.


                Но лучше тут конечно неймспейсы наверное сделать всё-таки, если что-то делать. Просто красивее выйдет в итоге для нашего проекта, как мне кажется. А что насчёт ядра PHP — то там как-то они всё равно очень логично всё делают, даже без неймспейсов.


                1. Fesor
                  13.02.2017 17:42
                  #10067996
                  +1

                  Префиксы тогда должны быть например так

                  вообще-то нет. У вас префикс — ace_editor — определяет к какому модулю они принадлежат.


                  Но лучше тут конечно неймспейсы наверное сделать всё-таки, если что-то делать.

                  Да, выйдет что-то типа


                  use function {aceEditor\parse};

// ...

parse($str);


                  1. saggid
                    13.02.2017 17:48
                    #10068008

                    Всё-таки не так на самом деле. Для этого ейс эдитора всего одна функция в проекте. И она лежит среди других функций для работы со строками.


                    image


                    Поэтому я и говорил о том, что в нашем проекте если неймспейсы делать функциям, то можно сделать например… вот так, чтоли:


                    namespace App\Functions\Strings;

function ace_editor_parse() {
  //...
}

                    Но в данный момент я лично не ощущаю в этом нужды. И так всё вполне красиво и удобно.


                    1. Fesor
                      13.02.2017 19:30
                      #10068200

                      Вот вы в своем коде указали что используете функцию bcrypt. Вместо нее стоило бы использовать абстракцию — password_hash. Заметте то обе эти функции не будут лежать в нэймспейсе string так как то что они используют строки в качестве значений, это не основная цель. Точно так же и ваш ace_editor_parse — его задача не просто со строками работать, а парсить с какой-то целью (скорее всего что-то связанное с ace_editor). Ну и исходя из этого и надо дробить на модули.


                      1. saggid
                        14.02.2017 03:10
                        #10068722

                        Вместо нее стоило бы использовать абстракцию — password_hash

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


                        С остальным согласен, оно немного не до конца хорошо раскидано) но опять же. Работе сильно не мешает. Как-нибудь может немного наведу там порядок просто, раскидаю функции по более корректным папкам)


            1. Fesor
              13.02.2017 17:38
              #10067986
              +4

              эх… ох уж этот глобальный доступ к зависимостям...


            1. Metus
              13.02.2017 22:58
              #10068496
              +1

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


              public function isCurrentUser()
{
    return ($this->id === current_user()->id);
}

              Если я вижу такое у кого-то из коллег, то требую переписать.


              У вас current_user() как определяется? Я полагаю, берётся из сессии, кук, заголовка — это всё накроется медным тазом, когда захочется вызвать данный код из консоли.


              Почему данные HTTP-запроса (или хз вообще какого запроса — тут не ясно) протекают в модель, которая вообще не должна быть привязана ни к какому интерфейсу взаимодействия с приложением? И как это тестировать?



                  event(new UserCreated($user));

    send_email_to_admins('У нас новый пользователь!', 'emails.user-registered', [
        'newUser' => $user,
    ]);

    // Отправим пользователю сообщение-приветствие
    send_email_to_user('welcome', $user);

    session(['first-login' => true]);

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


              И останется только:


               event(new UserCreated($user));

              И я ничего не говорю про то, что ваш код абсолютно не модулен и попытка использовать его без изменений вне рамок первоначального плана практически невозможна, как и тестирование. Это лапша.


              1. saggid
                14.02.2017 03:45
                #10068742

                Ну что вы сразу обидными словами кидаетесь) Всё прекрасно тестируется, не стоит торопиться с выводами.


                У вас current_user() как определяется? Я полагаю, берётся из сессии, кук, заголовка — это всё накроется медным тазом, когда захочется вызвать данный код из консоли.

                Не накроется, не беспокойтесь. Функция current_user() — это просто удобная обёртка над основным синглтон-классом авторизации Laravel:


                use App\Models\User;

function current_user()
{
    $current_user = Auth::user();

    if ($current_user === null) {
        $current_user = new User();
    }

    return $current_user;
}

                Класс Auth, в котором вызывается статический метод, тоже без всяких проблем тестируется: потому что это фасад Laravel, и он тоже идёт из коробки во фреймворке.


                В тестах у нас пишется вот такой код:


                    /**
     * Убедимся, что система даёт доступ на вход в админку
     * пользователю-админу
     */
    public function testAdminGrantAccess()
    {
        $adminUser = create_user('admin');

        $this
            ->actingAs($adminUser)
            ->visit(route('admin'))
            ->see(__('admin.panel'))
        ;
    }

                $this->actingAs($user) — стандартная функция из набора инструментов Laravel для тестирования проекта. Ну и да… оно вызывается из консоли.


                Тут я вообще не понял, такое ощущение, что прикрутили события после того как сделали отправку писем, но забыли сделать рефакторинг

                Я не особо согласен с этим. Не обязательно ведь теперь засовывать в реакцию на эвент вообще всю логику создания пользователя. Просто есть основные действия при создании пользователя, которые являются ядром проекта, и есть некоторые дополнительные, которые выполняются модулями проекта. Поэтому для модулей и был сделан эвент.


                1. Metus
                  14.02.2017 09:21
                  #10068904
                  +1

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


                  1. saggid
                    14.02.2017 09:25
                    #10068916
                    -1

                    Чтобы я увидел реальную проблему, опишите пожалуйста ситуацию, когда это будет мешать нормальной работе проекта. Только не какие-то абстрактные идеи и предположения, пожалуйста. Какой-то конкретный юз-кейс.


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


                    1. Metus
                      14.02.2017 09:38
                      #10068942
                      +1

                      Проблема в том, что с одной и той же моделью можно работать разными способами — запросы будут разные.


                      Сейчас она обращается к сессии.


                      Потом понадобилось сделать консольную команду (не тест), чтобы сделать что-нибудь с пользователями. Как в данном случае будет работать Auth::user()? Как сделать пользователя авторизованным?


                      1. saggid
                        14.02.2017 09:49
                        #10068962
                        -1

                        Проблема в том, что с одной и той же моделью можно работать разными способами — запросы будут разные.

                        Не понял проблему. Опишите пожалуйста более конкретную ситуацию.


                        Сейчас она обращается к сессии

                        Да не к сессии эта функция обращается) А к синглтон-сервису в ларавел фреймворке, я ведь написал)


                        Указать, какой пользователь в данный момент авторизован — очень просто. Вам поможет любой из методов, описанных в официальной документации к Laravel.


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


                        1. Metus
                          14.02.2017 10:04
                          #10068996
                          +1

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


                          И да, можно сделать так


                          Auth::login($user);
// и совсем в другой части проекта
$u->isCurrentUser();

                          И всё это будет работать. Но это будет понятно только тому, кто изначально писал этот код.


                          1. saggid
                            14.02.2017 10:40
                            #10069076
                            -1

                            Всё-таки, снова слона из мухи раздуваете.


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


                            1. Metus
                              14.02.2017 10:51
                              #10069100

                              Сервис авторизации стандартный, но использование его нестандартное.


                              Есть объект $user.


                              Человек видит в нём метод isCurrentUser. Без копания в коде (а в идеале нужно смотреть только на сигнатуру метода) не понятно как заставить его работать, и будет ли он работать вообще без дополнительных манипуляций.


                              Что делать разработчику?


                              • Будет ли метод работать сразу, потому как мы обрабатываем http-запрос?
                              • Нужно ли вызывать Auth::login снаружи, т.к. http-запрос отсутствует?
                              • Нужно ли делать ещё что-то?

                              Всё это неясно. Именно в этом проблема таких неявных и при этом жёстких зависимостей.


                              Объект должен быть максимально самодостаточным и его зависимости должны быть явными. Если этого нет — его просто неудобно использовать.


                              1. saggid
                                14.02.2017 11:09
                                #10069150
                                -1

                                Ну у вас опять начинается теоретика. Я ведь просил без неё.


                                В ларавел не зря есть понятие сервис-провайдеров, а также двух этапов их инициализации: регистрация и загрузка.


                                Уже после этого будет запущен различный код вашего приложения. Будь то консольная команда, будь то ваше API, или же самый обычный GET-запрос на вебсайт.


                                Если вы будете отталкиваться от архитектуры фреймворка, у вас не будет возникать этих вопросов, которые вы сейчас задаёте. Да, надо знать немного больше. Да, это выходит за рамки каких-то типичных абстрактных Единственно Истинных правил написания ПО. Если для вас критично им следовать — то я могу только сказать, что это просто ошибочное мышление.


                                Как пишет Стивен Макконнел в своей книге "Совершенный Код":


                                Как сказал Ф. Дж. Плоджер, «чем догматичнее вы будете в отношении методики проектирования, тем меньше реальных проблем решите» (Plauger, 1993). Рассматривайте проектирование как грязный, неряшливый эвристический процесс. Не останавливайтесь на первом проекте, который пришел вам в голову. Сотрудничайте. Стремитесь к простоте. Создавайте прототипы, если нужно. Не забывайте про итерацию. Вы будете довольны своими проектами.

                                Очень хороший абзац, на мой взгляд. Поразмышляйте над ним, особенно над первым предложением в нём.


                                1. Metus
                                  14.02.2017 11:42
                                  #10069260
                                  +1

                                  Какая уж тут теоретика?


                                  Конкретный случай. Разработчику нужно вызвать код


                                  $user->isCurrentUser()

                                  Он знает, что этот метод корректно работает в контроллере.
                                  Но сейчас ему нужно вызвать этот код в консоли, а завтра в контексте API-контроллера.


                                  Будет ли это работать без предварительных приготовлений где-то в сервис-провайдере? Нет.


                                  Знает ли об этом разработчик? Нет. Всё что у него есть — это метод, который каким-то образом (видимо, по контексту вызова) определяет, авторизован пользователь, или нет. Как он определяет — разработчик не знает. Он и не должен знать — инкапсуляция.


                                  К вопросу о простоте, он мог бы вызвать:


                                  Auth::user() && Auth::user()->id == $user->id

                                  и он знал бы, что обращается к сервису авторизации, который может быть как-то сконфигурирован как угодно.


                                  Он мог бы сделать ещё проще, в случае, если ему приходит токен в заголовке и работа с сессией не нужна.


                                  $headerUserToken == $user->token

                                  Но у него есть этот волшебный метод isCurrentUser, который скрывает всю информацию об использовании сервиса.


                                  • Использует ли он какие-то сервисы — разработчик не знает.
                                  • Будет ли работать он, если пользователю пришёл HTTP-заголовок secret_user_token — он не знает.
                                  • Будет ли работать он, если второй и третий аргументы командной строки являются логином и паролем — он не знает.

                                  Он и не должен ничего этого знать.


                                  Почему Вы всё время пытаетесь рассказать как работают сервис-провайдеры в ларавеле? Мои претензии не к ним, а непосредственно к модели User.


                                  1. saggid
                                    14.02.2017 16:24
                                    #10070068
                                    -1

                                    Потому что вполне нормально, что авторизация может работать на уровне сервис провайдеров или middleware. Поэтому я вам и указываю на них.


                                    Абсолютно нормально, что один уровень приложения зависит от другого уровня приложения. И ведь точно также, указанный вами код Auth::user() && Auth::user()->id == $user->id будет зависеть от всего, что вы перечислили.


                                    Если вы это не хотите признавать, почему это должно быть моей проблемой? Я же просто добавил удобный метод для модели пользователя.


                                    1. Metus
                                      14.02.2017 17:33
                                      #10070250
                                      +1

                                      Конечно нормально. В приложении всегда один уровень зависит от другого.


                                      В тему цитат приведу первые 4 строчки философии python:


                                      • Красивое лучше, чем уродливое.
                                      • Явное лучше, чем неявное.
                                      • Простое лучше, чем сложное.
                                      • Сложное лучше, чем запутанное.

                                      Метод isCurrentUser неявный и запутанный.


                                      Неявный потому как данные зависимости, простите за тавтологию, не являются явными.


                                      Запутанный из-за того, что зависимость кольцевая: модель пользователя (модель бизнес-логики) зависит, от сервиса более высокого уровня (который её и использует).


                                      1. saggid
                                        14.02.2017 17:46
                                        #10070302

                                        Оно вполне явное и вполне простое. Вот вы реально нашли такую мелочь и пытаетесь из неё хоть что-то вывести.


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


                                      1. ellrion
                                        14.02.2017 18:15
                                        #10070368

                                        Т.е. вы предлагаете везде копипастить код ?


                                        Auth::user() && Auth::user()->id == $user->id

                                        Ну это тоже не дело.


                                        Явное лучше, чем неявное

                                        Но повторение кода тоже зло. Именно из-за этого есть "магия" которая позволяет убрать копипаст. Так что тут нужен баланс и компромисс.


                                        1. Metus
                                          14.02.2017 19:19
                                          #10070550

                                          Нет, я предлагаю вынести метод isCurrentUser из модели. При желании, расширить Auth и вынести данную логику туда.


                                          Либо можно вообще сделать трейт для контроллеров. Потому как решать, авторизован пользователь или нет должны именно они.


                                    1. Fesor
                                      14.02.2017 22:51
                                      #10071002
                                      +1

                                      Абсолютно нормально, что один уровень приложения зависит от другого уровня

                                      Нормально — это когда у нас нижние уровни не зависят от верхних. У вас же штуки из верхних уровней тянутся вниз.


                                      Если вы это не хотите признавать, почему это должно быть моей проблемой?

                                      я в своем коде в модулях нижних уровнях просто передаю юзера если надо. Они не лазают за ними сами. Это и удобнее, и читается проще, и с точки зрения масштабирования логики норм. И самое интересное — это не дольше по времени. То есть минусов вообще никаких. Ну и в Laravel5.3+ нормальный IoC есть что бы не страдать чушью из 4-ой.


                                      1. saggid
                                        15.02.2017 03:07
                                        #10071288

                                        Ну и в Laravel5.3+ нормальный IoC есть что бы не страдать чушью из 4-ой

                                        Можете привести какие-то конкретные примеры, чего "нормального" появилось в сервис контейнере в ларавел 5.3+?


                                        Ну и я снова не сильно согласен в целом. Опять до фанатизма доходите, извините. Пусть в одном месте проекта у нас вытаскивается модель текущего пользователя. Текущий пользователь — он на то и текущий. Он один. Его даже менять не нужно в 99% ситуаций жизни проекта, но даже если поменяешь в основном синглтон классе авторизации — то в других местах приложения всё отработает как полагается. Да, это чуть чуть менее явно, также как с эвентами, про которые я вам уже говорил в другом комментарии. Но я не могу назвать это полностью плохим подходом, который не имеет права на жизнь. Иначе и эвенты бы тоже надо было закидать камнями, но почему-то этого ведь никто не делает?


                                        1. Fesor
                                          15.02.2017 10:20
                                          #10071660

                                          Но я не могу назвать это полностью плохим подходом, который не имеет права на жизнь.

                                          Так как бы я этого и не говорю. Для маленьких/средних проектов с учетом нормальных сервис-локаторов ларавели жить можно.


                                          Иначе и эвенты бы тоже надо было закидать камнями

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


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


                                          Словом, все относительно. Нет абсолютных правил. Но есть лучшие практики которым стоит придерживаться.


                                        1. pbatanov
                                          15.02.2017 14:41
                                          #10072410

                                          С чего бы эвенты надо закидать камнями? Эвенты — это документированная точка расширения вашего приложения, вы как бы говорите разработчикам — «Э-гей, вот здесь вы можете изменить мир данные или отреагировать на них, вот вам событие, которое их инкапсулирует». Событие вполне себе может быть VO, если планируется только реакция на событие, или может быть мутирующим, если вы хотите чтобы расширения как-то дополнили или изменили ваши данные. Т.е. вы сами полностью управляет процессом реакции на события за счет паттернов.

                                          Не знаю за ларавель, но в симфони евенты, как и все остальное, полностью DIC-based, это значит что можно найти все зарегистрированные листнеры (либо посмотреть в рантайме, если вы подписываетесь в рантайме).

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

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


                    1. Metus
                      14.02.2017 09:45
                      #10068956
                      +1

                      Помимо классических HTTP-страниц и консоли, Ваше приложение может выступать в роли API-сервера, а там вообще довольно часто авторизация определяется токеном, который клиент отправляет в заголовках запроса — без всяких сессий.


                      1. saggid
                        14.02.2017 09:51
                        #10068966
                        -1

                        Ответил вам наверху на вопрос по этой теме) Уверяю вас, это не проблема. Просто авторизуем пользователя самостоятельно, так, как вам нужно.


    1. Fesor
      13.02.2017 10:57
      #10066964
      +3

      пишущим качественный ООП-код?)

      нэймспейсы не имеют никакого отношения к ООП. Это просто способ сделать более удобное API, без префиксов. Там внутри просто функции.


      1. saggid
        13.02.2017 15:05
        #10067608

        Это да, ошибся просто когда писал. Имел ввиду это.


  1. vshemarov
    13.02.2017 09:16
    #10066844
    +1

    Немного удивляет упорство людей, которые так настойчиво пытаются внедрить короткий синтаксис. Прям какая-то «битва за сахар»


    1. ellrion
      13.02.2017 10:25
      #10066908
      +1

      удивляет нежелание его принимать. Последнее время ананимок в коде очень много. И код бы стал гораздо приятнее.


      1. Fesor
        13.02.2017 10:59
        #10066972
        +1

        Сейчас напоролись на то что ключевое слово fn не хотят вводить (есть же function уже). Ну и в целом будет нарушение обратной совместимости. Потому обсуждается альтернативый вариант синтаксиса:


        $fn = |$x| => $x * 2;

array_reduce($arr, |$str, $chunk| => $str . $chunk, '');


        1. ellrion
          13.02.2017 11:05
          #10066988

          по мне так fn выглядит самым приятным и логичным из 4 вариантов (5 если считать еще и |). Как раз сокращенное function.


          1. Fesor
            13.02.2017 11:19
            #10067022

            оно всем нравится, но если у вас в коде есть функция с именем fn то при обновлении все сломается, чего нельзя делать до выхода 8-ой версии. Потому возможный компромис это |$x| => $x.


        1. LastDragon
          13.02.2017 11:05
          #10066990
          +2

          мдя… чем, интересно, широкоиспользуемый () => $x * 2; не нравится? (парсер же вроде нормальный уже?)


          1. Fesor
            13.02.2017 11:23
            #10067032
            +3

            (парсер же вроде нормальный уже?)

            Да, нормальный LR(1) парсер. Что значит единичка? Это означает что дальше чем на одину лексему вперед вам видеть не дают. То есть вы должны понимать является ли выражение лямбдой либо с самого первого токена либо на один токен вперед.


            С выражениями типа $x => $x * 2 проблема заключается в том, что => используется в разных контекстах и с такой записью невозможно точно определить что это за выражение не разобрав его до конца. Ну и в целом остаются конфликты с yield $key => $value. Потому без ключевого слова или специального символа в начале лямбды не обойтись.


            Если что в python например ввели ключевое слово lambda, в ruby у нас примерно такой же вариант как предлагают в php: |x| => x * 2 ну и т.д.


        1. Miraage
          13.02.2017 14:13
          #10067418

          Блоки из Ruby что ли?


      1. franzose
        14.02.2017 14:35
        #10069678

        И вы, кажется, даже в слове «анонимок» не сделали ошибки в контексте данного случая...)


    1. Fesor
      13.02.2017 10:57
      #10066968
      +4

      вы видимо просто не представляете насколько это удобно.


      1. Metus
        13.02.2017 22:40
        #10068472

        Это, конечно, удобно.


        Но у нас есть некий "use", потому лямбды надо делать либо с ним, либо вообще отказываться от этого "use". Т.к. иначе это будет ещё одна несогласованность в языке.


  1. TrogWarZ
    13.02.2017 12:25
    #10067124

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

    И дело не в том, что писать на сколько-то символов больше (автокомплит IDE нивелирует), а в том, что текущий синтаксис сильно «шумит» – у меня бывает, что «накладные символы» по длине такие же как полезное действие в функции, – такое сложно распарсить глазами и понять.
    Да и IDE обычно фолдит такие вещи – приходится кликать в однострочники чтобы посмотреть что они делают что-то похожее на array_column, только для объектов или считают среднее арифметическое по аттрибуту из коллекции. С коротким синтаксисом это распознаётся глазом гораздо быстрее. По крайней мере, лично моим – точно быстрее.


    1. gro
      13.02.2017 12:51
      #10067192

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


      1. Fesor
        13.02.2017 13:17
        #10067262

        новый будет сливаться.

        как напишите так и будет. Не спроста в текущих RFC не предлагается поддержки нескольких выражений на лямбду. Это слегка противоречит идее "функциональных выражений". Так что сливать не должно.


        JS со стрелочными функциями последнее время всё больше на brainfuck похоже становится.

        Да нет, как раз таки все хорошо. Бывает что разработчики злоупотребляют но… в среднем выходит читаемо.


    1. Fesor
      13.02.2017 13:16
      #10067258
      +1

      пока не ввели какой-то синтаксис для лямбд и вы работаете в продуктах Jetbrains можно этим пользоваться: https://github.com/vkurdin/idea-php-lambda-folding


      1. TrogWarZ
        13.02.2017 13:45
        #10067316

        Так гораздо удобнее, спасибо!


  1. Anexroid
    13.02.2017 14:22
    #10067458
    +2

    hannob/php-crashers — Примеры скриптов, которые вызывают segfault в PHP

    Неверно, там всё таки примеры не с segfault в классическом его понимании, а банальная бесконечная рекурсия, таких примеров можно миллион сделать.