Laravel Чем вызван взрывной интерес к Лярве?

[grigori]

вообще, это был толстый вброс yii меня достает ничуть не меньше
автоматическая инъекция в ларавеле - не более, чем сахар, а yii таким же сахаром прописывает поля и связи "моделей" по таблицам базы

fixxxer, ты такой правильный и мудрый, как дедушка )))

@AmdY я имел ввиду yii1

 

[Adelf]

Это не сахар. А вещь весьма необходимая в более-менее больших проектах. В Yii оно есть, но куцее и юзается только внутри фреймворка, в основном. Юзерами юзается SL.

 

[fixxxer]

Побуду еще немного дедушкой

DI - это такой очень важный, основополагающий сахар для объектно-ориентированного программирования. Ключевые слова class и interface - тоже, можно сказать, сахар: объектно-ориентированные программы вполне можно писать и без них, но это значительно менее удобно.

 

[artoodetoo]

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

По определению же DI это просто делегирование создания входящих зависимостей внешнему сервису.

 

[Adelf]

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

 

[Вурдалак]

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

По определению же DI это просто делегирование создания входящих зависимостей внешнему сервису.

Да забей ты на способ конфигурации, вполне норм. А что до DI в целом, то Грише по привычке рассказывают про DI over SL, это уже местная традиция.

 

[artoodetoo]

@Adelf, Я не говорю, что это было изобретено для пхп. Это используется в пхп с недавних пор. И не факт что абсолютное добро. И точно это не единственный способ реализации IoC.
Поэтому я слегка агрюсь когда дедушки рассказывают как здорово, что в ООП есть DI (имея в виду конкретную магическую реализацию). Может и здорово, но это не канон.

 

[Вурдалак]

имея в виду конкретную магическую реализацию

Тебе показалось.

 

[fixxxer]

DI не означает ничего подобного

Никто этого и не говорил, DI бывает разный. Важно, чтобы был, и достаточно удобный, чтобы неудобства не вынуждали использовать контейнер как SL. Разницу между DI и SL ты понимаешь, надеюсь?

 

[artoodetoo]

Да, дедушка, понимаю. SL не обязательно "вынужденно". Боюсь сейчас начну ходить по кругу.
Давай так подойдем: где в приложении не стыдно иметь зависимость от фреймворка?

 

[hell0w0rd]

Да, дедушка, понимаю. SL не обязательно "вынужденно". Боюсь сейчас начну ходить по кругу.
Давай так подойдем: где в приложении не стыдно иметь зависимость от фреймворка?

да везде, если у тебя есть сроки А если нет - можно не зависеть от фреймворка, базы, ОС, кол-ва памяти, fs и тд и тп.

 

[artoodetoo]

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

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

 

[Вурдалак]

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

Это глупость какая-то. Есть класс, есть конструктор, в конструкторе прописан интерфейс в type hinting. Вот эта хрень в конструкторе — это зависимость. Если этот интерфейс не принадлежит фреймворку, то зависимости от фреймворка нет.

А если ты зависимостью называешь конфигурацию, то с тем же успехом можно сказать, что в Symfony тоже существует зависимость от DI-конфигурации компонента Symfony DIC.

А что касается action(User $user), то это примерно то же самое, что и http://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html
Я хз как в Laravel, но в Symfony такая «инъекция» в action разруливается не контейнером.
И мы, я так понимаю, всё-таки не про это.

Тебя просто не устраивает способ конфигурации контейнера в Laravel?

 

[Adelf]

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

 

[Redjik]

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

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

камень в сторону этой магии в ларке - вообще могли бы и куданить кешировать весь DIC, чтобы каждый раз reflection не дергать, симфони вон свой конфиг кеширует

 

[grigori]

Мне нравится инъекция по тайпхинту. Это сахар, который легко реализуется, хотелось бы добавить его в симфони.
Еще мне нравится Blade. Простой, очень интуитивный. На этом список того, что нравится, заканчивается.

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

Чем больше проект, чем больше будет разработчиков разного уровня, и чем дольше нужна поддержка кода - тем больше вреда будет от Laravel.
Документация - неполные примеры на фасадах без описания всех параметров, остальное - викторина. По Ctrl-click перехода на реализацию нет - у нас же маппинг интерфейсов.
Я раз 50 спрашивал Adel о простейших вещах, которые без ларавеля пишу по памяти.

За последние пару дней я потерял точно больше 5 часов:

Выставить режим PDO::FETCH_COLUMN? только глобально для всех запросов из фреймворка, и фреймворк сходит с ума, даже если после запроса я вернул старое значение. Это противоречит API PDO, потому что fetch mode у Statement? Кого волнует предсказуемость, творец так видит.

Как выставить куке http-only? В доке $response->withCookie(cookie('name', 'value', $minutes)); Так надо вызывать CookieJar::queue()! Что ж я не телепат-то?

Обязательное шифрование кук. А как дебажить выставление кук при AJAX-запросе? Надо развивать телепатию. Или танцевать с вардампом.

Гугл выдает почти все ссылки на доку по 4, там приведен пример вывода вызовом \Response::make("data") , который в 5 вызывается без ошибок, но ничего не выводит.
А в 5 пример - return new \Illuminate\Http\Response("data");
Это как в новой версии php print() выполнялся бы без ошибки, но не выводил данные, а перед ним надо было бы добавить echo.

Дерьмо с сахаром. Модное, стильное, молодежное дерьмо.

 

[Alexey Mezenin]

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

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

Ах да, это все неправда, просто Отвелл и Джобс - гениальные маркетологи, которые продают гомно, а армия пользователей их продукции - просто легкомысленные гоблины.

За последние пару дней я потерял точно больше 5 часов

А можно было задать грамотный вопрос гуглу, благо ответ на любой вопрос, касательно Laravel, гугл сразу отвечает.

Или задать хорошо сформулированный вопрос на Laracast, Laravel.io или StackOverflow. Ответ прилетит очень быстро.

Дерьмо с сахаром. Модное, стильное, молодежное дерьмо.

То же можно сказать и об Yii. Только оно без сахара и магии, уже не модное и никогда не было стильным.

 

[Adelf]

@grigori, я тоже когда-то первый раз на laravel писал. И таких проблем не было. Есть документация, где есть ответы на 90% вопросов.
Мне показалось что у тебя стиль такой - решать задачу в лоб("о простейших вещах, которые без ларавеля пишу по памяти."). Т.е. тем способом, который ты считаешь очевидным. А стиль мышления у разработчиков ларки, похоже, просто сильно отличается от твоего. Вот и вся проблема.

 

[Вурдалак]

Шёл 2016-й, а люди продолжают спорить о фреймворках. Как лучше выставить куки, каким способом сфетчить данные из базы, как написать «Hello, world». Интересные обсуждения, горячие темы, захватывающие дискуссии.

По Ctrl-click перехода на реализацию нет - у нас же маппинг интерфейсов.

Проклятый Laravel, заставляет следовать DIP.

 

[grigori]

Проклятый Laravel, заставляет следовать DIP.

DI - это очень хорошо, и в документации нужно показывать именно такие примеры,
а ларавель везде в доке учит говнокоду на статических вызовах, проповедует костыли,
прячет API, делает правильную DIP-реализацию весьма трудоемкой, с необходимостью писать без документации, без тайпхинтов, и обламываться на BC break