Тролллинг на тему трейтов

[grigori]

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

Trait ActionOne{
    public function run(){}
}
Trait ActionTwo{
    public function run(){}
    public function foo() {}
}
Trait TT {
  use ActionOne, ActionTwo {
    ActionOne::foo insteadof ActionTwo;
  }
}
$app->get('/', new Class {use TT; });

 

[Adelf]

@grigori, попадешь на седьмой круг ада и будешь вариться в котле со своими же трейтами ;-)

 

[MiksIr]

Хочу на море Сдауншифтить что ли...

 

[Вурдалак]

Чем бы Гриша не баловался, лишь бы с ним в одном проекте не работать

 

[grigori]

вынес множественное наследование экшенов контроллера - это шутка, конечно

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

 

[Вурдалак]

Так вроде как всё наоборот, это ты недавно возбудился, вспомнив про трейты, минусы которых мы давно поняли.

 

[grigori]

Я тоже вроде бы разобрался года 3 назад, а тут почитал Slim когда дебажил в нем багу, и осознал, что не разобрался.

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

 

[c0dex]

Я уже давно скис

 

[Вурдалак]

Ну, мы просто пока не доросли до твоего уровня, Гриш. Подними вопрос трейтов на какой-нибудь конференции. Расскажи про синтаксис, основные моменты. Я думаю, это будет успех.

 

[Adelf]

Не поленился. Посмотрел Slim. Два простеньких трейта... где там откровение то?

 

[hell0w0rd]

Я последнее время считаю, что лучше написать больше кода, но максимально понятный. С кучкой трейтов приходится в голове держать их все при попытке разобраться что же в коде написано. Пока работаешь над конкретно этим проектом и у тебя не то что трейты, весь проект знаешь - норм. Но если прийдется вернуться и что-то допилить, или новый разработчик прийдет - сложно вникнуть.
По той же причине в React стали потихоньку отказываться от миксинов. А они как раз почти трейты в php.

 

[Вурдалак]

Я трейты на практике использую только как сахар для записи событий в aggregate root. Типа такого: https://github.com/event-centric/EventCentric.Core/blob/4b07925355b49f12f91a99df12fabcab5462785d/src/EventCentric/AggregateRoot/EventSourcing.php
Тут нет каких-то сайд-эффектов, зависимостей. Мои сущности в базу не лезут.

 

[hell0w0rd]

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

 

[Вурдалак]

Композицию можно, если ты введешь что-то типа class EventHistory, но

• это длиннее: $this->eventHistory->record(new UserWasBanned()) против $this->record(...) + инициализация
  
• реализация интерфейса TracksChanges в том или ином виде будет копироваться (хотя бы на уровне return $this->eventHistory).

Этот кейс как раз более-менее подходит для трейта. Плюс может появиться желание писать события в стиле event sourcing с методами а-ля whenUserWasBanned и тут либо пилить абстрактный класс, либо трейт. Будет примерно одинаково.

Это ппц как сложно в такой код будет въезжать.

В сомневаюсь, что в этом тут будет виноват трейт. Аргументы вроде «будет сложно въезжать» — это интуитивное «я знаю, что будет плохо, но не могу объяснить почему».

А так да, в 99% случаев нужна композиция вместо трейта.

 

[AmdY]

Я трейты на практике использую только как сахар для записи событий в aggregate root. Типа такого: https://github.com/event-centric/EventCentric.Core/blob/4b07925355b49f12f91a99df12fabcab5462785d/src/EventCentric/AggregateRoot/EventSourcing.php
Тут нет каких-то сайд-эффектов, зависимостей. Мои сущности в базу не лезут.

Да, @grigori , тебе с твоими говнотрейтами и разработкой тяп-ляп, не понять, сколько денег на серьёзном проекте с DDD можно распилить на простой фиче вроде возможности добавить в корзину больше одной единицы продукта. http://buttercup-php.github.io/protects/04-ProtectsInvariants.html
Static + final и за одну фичу уже можно позволить себе новую тачку.

 

[grigori]

Не поленился. Посмотрел Slim. Два простеньких трейта... где там откровение то?

не откровение, просто лаконичность

$app->get('/foo', function ($req, $res, $args) {
    $myService = $this->myService;
    return $res;
});

Приложение там оформлено как трейт.
Контроллер оформлен как лямбда и "монтируется" в контейнер, и получается, что сервисы, зарегистрированные в контейнере, становятся доступны через $this.
Это навело меня на мысль о том, что подобный результат можно получить трейтами в общем случае, не только для замыканий.

@Вурдалак, я серьезно считаю, что единственная сфера, в чем ты достиг серьезных результатов - это петросянство и сарказм. Может, они есть и в программировании, но за все годы ты не представил ни одного своего личного решения или идеи - удачных или нет. Только цитаты.

 

[Вурдалак]

@grigori Ой, как обидно слышать это от тебя, Гриша. А, хотя нет, не обидно

 

[scorpion-ds]

Недавно написал вот такй трейт и как раз для контроллера:

namespace CP\SecurityBundle\Controller;


use CP\AccountBundle\Entity\Account;
use CP\SecurityBundle\Entity\CheckAvailableForAccountInterface;

trait ControllerTrait
{
    /**
     * @param Account $account
     * @param CheckAvailableForAccountInterface $object
     * @return bool
     */
    protected function availableObjectForAccount(Account $account, CheckAvailableForAccountInterface $object)
    {
        if($account->getId() != $object->getAccount()->getId())
        {
            return false;
        }

        return true;
    }

    /**
     * @param CheckAvailableForAccountInterface $object
     * @return bool
     */
    public function availableObjectForCurrentAccount(CheckAvailableForAccountInterface $object)
    {
        return $this->availableObjectForAccount($this->getCurrentAccount(), $object);
    }

    /**
     * @return Account|bool
     */
    protected function getCurrentAccount()
    {
        $account = parent::getUser()->getAccount();
        if(!$account instanceof Account)
        {
            return false;
        }

        return $account;
    }

}

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

 

[hell0w0rd]

А почему нельзя в CheckAvailableForAccountInterface добавить метод isAvailableFor(Account $account); и его дергать?

 

[scorpion-ds]

А почему нельзя в CheckAvailableForAccountInterface добавить метод isAvailableFor(Account $account); и его дергать?

Это сущность БД, но можно ведь ... , в общем это идея, наверно так и сделаю, я пока только начинаю работу над проектом ...