Упаси нас все боги от такого core разработчика) Человек прибывает в своем мирке. Он сам не понимает что не предлагает ничего нового. И смена языка ему ничем не поможет. Хотя ему с его тягой к KISS (хотя я считаю, что у него свое извращенное понятие этого принципа, но всё же) можно посоветовать разве что golang попробовать.
Тут большинство считает, что его слова адекватны. Качали мы уже всё. Нет спасибо такого нам не надо. Наш код проще. Аналогии конечно последнее дело, но никак не могу отделаться от мысли что автор настоятельно втирает всем булыжник вместо например Беретты.
Идейно тоже нет ничего нового. или напиши только чётко и без воды хоть один (лучше просто один) тезис что ты предложил.
О да, это было очень умно. Нечего сказать не по одному из пунктов? Собственно как говорят "слив засчитан".
Повторюсь ваш код ужасно сложен. Он, как тут было верно сказано, простецкий а не простой. А вы путаете эти понятия. И плюс учитывая что сами писали эти несчастные несколько файлов и мусолили их по много раз вот он и кажется вам простым. Код огромного Ларавель в котором есть функционала в сотню раз больше проще в разы чем ваши "крылья".
Но можно условно назвать идеальным код, который проанализирован огромным количеством программистов и активные итерации по совершенствованию которого, не прекращаются никогда.
Автор, по твоему собственному определению код современных фреймворков например laravel идеален. Более тысячи контребьютеров. Изменения вносятся ежедневно. А к тому же используются компоненты над которыми работали еще тысячи. Что ты на это скажешь?
Вот именно! Я искренне не понимаю ту часть сообщества хабра которая поддерживает автора. Он скрываясь за собственными терминами и словоблудием продвигает пару вполне нормальных истин. "Простота — хорошо"; "Опенсоурс — хорошо"; "Слепое следование любым постулатам — плохо". Но при этом сам же автор всё это нарушает абсолютно.
Не понимает, что проектов в которых десятки опытных разработчиков УЖЕ ведут разработку вместе и шлифуют код полно. И Флагман это гитхаб. И такая коллективная работа ведется как раз над современными фреймворками, которые так не нравятся автору. Достаточно открыть вкладку с контребьютерами. Но нет нужно там всё бросить и делать скай, ибо там все силы тратятся в пустую.
Говоря что нельзя быть слепым следователем каких то постулатов, сам пишет о слепом следовании KISS при этом в каком то своем понимании.
И самое имхо главное то что он уже сделал это плохо, вот именно ПЛОХО. Говоря что современные подходы только вносят сложность, сам код написал так что в нем невозможно разобраться, он ужасно СЛОЖНЫЙ. Да я быстрее в ларе прикрутил бы броадкастинг эвентов через реббит, при этом сделал бы это всё используя подход фреймворка, и в слое самого приложения вообще бы не было разницы со стандартными методами броадкастинга. Чем в приложении автора пойму откуда какая переменная прилетела и откуда например на какой то строчке есть $user хранящая данные аутентифицированного пользователя. Не говоря уже о каких то сложных вещах типа нескольких одновременных аутентификациях.
А использования тысячи переключалок в визуальной утилите еще сложнее. Я бы быстрее код ядра фреймворка прочитал и понял.
Нет простоты у тебя автор. Никакой
Однако разработчики фреймворка явно не рассчитывали на то, что количество поддерживаемых СУБД может расширяться за счёт сторонних пакетов. Об этом говорит то, что в классе фабрик подключений Illuminate\Database\Connectors\ConnectionFactory имена классов подключений перечислены явно.
Вы не правы. Не до конца разобрались. За непосредственно работу с подключениями отвечает DatabaseManager implements ConnectionResolverInterface. Он уже в свою очередь использует ConnectionFactory, которая содержет работу с встроенными (доступными из коробки) типами подключений. но стоит посмотреть на метод makeConnection (https://github.com/laravel/framework/blob/5.3/src/Illuminate/Database/DatabaseManager.php#L156-L177) Видим что тут есть проверка на наличие экстеншена, и только потом если его нет то идет обращение к стандартной фактори.
т.е. у вас в коде сервис провайдера должно быть что то вроде
<?php
/...
$this->app->extend('db', function (DatabaseManager $manager) {
return $manager->extend('firebird', function() {
return new FirebirdConnector;
});
});
Серьезно? Это в каком информационном "коконе" вы прибывали что приведенные ссылки для вас оказались в новинку и вы теперь "думаете что делать". Неужели вы с 2012ого по 2016 (как указано на сайте вашего творения) не слышали о composer, PHP FIG и "постулатах" right way.
Или я не верно понял ваш комент...
Где то в своем скриптике тихо мирно выбрал я значит из бд пользователей в $users массив сложил. Потом надо мне их проитерировать, ну я и пишу foreach ($users as $user) И всё сломал ибо вы такой умный и у вас $user это глобал который хранит авторизованного пользователя.
Да какая тут может быть критика. Критика это когда "Хм интересно, но я не согласен по паре пунктов." У вас же всё плохо. Нет, серьезно, нет ни одного файла, функции, да практически строчки кода которые были бы нормальными.
Килотонны пафоса зато. Мне сначала было забавно, но чем больше тут от вас комментариев и тем мне страшнее. "Чувак, да что блин с тобой не так?"
Но давайте попробуем "покритиковать". Давайте не будем затрагивать что то уровня использования ООП, eval и глобалы — зло. если с 2012 по 2016(а именно так стоит на сайте) вы не прочли те сотни материалов что существуют и ваша практика так же вам не показала что тут что то не ладно, то думаю в паре комментов мы так же ничего не проясним.
Поговорим о том, что ваш код нарушает ваши собственные тезисы и конвенции.
Глобальные переменные и константы, которые предназначены для использования (могут быть затребованы) в любой части кода — пишутся заглавными буквами (за исключением переменных, которые имеют однобуквенный префикс), например $PROFILES. Однако (несмотря на положение переменной в глобальной области видимости), если логически переменная не подразумевает передачу своего значения в отдаленные части кода, а используется лишь в локальной части скрипта, в ее идентификаторе используются прописные буквы, например $i.
И этому идеально следуют такие повсеместно используемые прям центральные глобалы $sky и $user и многие другие (http://ru.coresky.net/code)
Да что тут говорить если вы льете кучу пафоса и рассуждений вида
проект всегда должен стремиться к тривиальной простоте, кристаллизация кода должна стать самой важной задачей проекта, важным фактором считать минимизацию необходимости прочтения документации.
но открыв самое простое что обычно есть в проекте — точку входа index.php я очень долго искал откуда же там у меня $user
Это можно продолжать и продолжать. Еще раз, плохо ВСЁ.
Серьезно, сложная? создать папку publick переусложняет структуру? А не забыть везде проверить START — не сложно. А еще если я захочу код вендоров притянуть то как мне обезопасить их? А какие то внутренние вещи типа кэша или файлов с внутренней документацией и т. д. и т. п.
Вариант с ограничением по константе не просто устаревший, он несостоятельный.
Большое вам спасибо! Вы только со статьей поспешили, завтра надо было выпускать. Но настроение подняли и даже не столько статьей, сколько шедевром «CoreSky.Net».
А типо, я до этого так сделать не мог? Уж извините это дает мне AR.
Вообще Вы что то мешаете всё в кучу. Начинался диалог с опровержения определения структурного паттерна. Давайте по пунктам.
1. То что в статье (какое бы оно ни было) это Декоратор. Он именно сохранил всё что умел предыдущий объект. И добавил то что тот не умел.
2. Нет это никакой не «паблик морозов» (хотя я вообще не уверен можно ли дискутировать про шуточный антипаттерн). Он не позволит обратиться к закрытым методам внутреннего объекта. Он им был бы если бы враппер (использовано в общем смысле) был бы наследником или того же класса что и внутренний объект.
3. В статье «презентор» не имеет отношения к MVP. Так же как и ваша попытка притянуть сюда архитектурный паттерн MVVM а точнее его часть ViewModel.
4. Стоит ли убрать магический call из конкретно таких презентеров? Да возможно стоит.
Ну вот так в Ларе это работает. Отойдите вы от понятий php и от конкретной реализации. Для модельки ее возвращаемые поля можно вполне считать интерфейсом. Презентер же берет и добавляет возможность взять еще какие то данные, сохраняя доступ к старым. И возвращаясь к теме ветки обсуждения это как раз Декоратор.
Упаси нас все боги от такого core разработчика) Человек прибывает в своем мирке. Он сам не понимает что не предлагает ничего нового. И смена языка ему ничем не поможет. Хотя ему с его тягой к KISS (хотя я считаю, что у него свое извращенное понятие этого принципа, но всё же) можно посоветовать разве что golang попробовать.
Тут большинство считает, что его слова адекватны. Качали мы уже всё. Нет спасибо такого нам не надо. Наш код проще. Аналогии конечно последнее дело, но никак не могу отделаться от мысли что автор настоятельно втирает всем булыжник вместо например Беретты.
Идейно тоже нет ничего нового. или напиши только чётко и без воды хоть один (лучше просто один) тезис что ты предложил.
О да, это было очень умно. Нечего сказать не по одному из пунктов? Собственно как говорят "слив засчитан".
Повторюсь ваш код ужасно сложен. Он, как тут было верно сказано, простецкий а не простой. А вы путаете эти понятия. И плюс учитывая что сами писали эти несчастные несколько файлов и мусолили их по много раз вот он и кажется вам простым. Код огромного Ларавель в котором есть функционала в сотню раз больше проще в разы чем ваши "крылья".
Автор, по твоему собственному определению код современных фреймворков например laravel идеален. Более тысячи контребьютеров. Изменения вносятся ежедневно. А к тому же используются компоненты над которыми работали еще тысячи. Что ты на это скажешь?
Вот именно! Я искренне не понимаю ту часть сообщества хабра которая поддерживает автора. Он скрываясь за собственными терминами и словоблудием продвигает пару вполне нормальных истин. "Простота — хорошо"; "Опенсоурс — хорошо"; "Слепое следование любым постулатам — плохо". Но при этом сам же автор всё это нарушает абсолютно.
Не понимает, что проектов в которых десятки опытных разработчиков УЖЕ ведут разработку вместе и шлифуют код полно. И Флагман это гитхаб. И такая коллективная работа ведется как раз над современными фреймворками, которые так не нравятся автору. Достаточно открыть вкладку с контребьютерами. Но нет нужно там всё бросить и делать скай, ибо там все силы тратятся в пустую.
Говоря что нельзя быть слепым следователем каких то постулатов, сам пишет о слепом следовании KISS при этом в каком то своем понимании.
И самое имхо главное то что он уже сделал это плохо, вот именно ПЛОХО. Говоря что современные подходы только вносят сложность, сам код написал так что в нем невозможно разобраться, он ужасно СЛОЖНЫЙ. Да я быстрее в ларе прикрутил бы броадкастинг эвентов через реббит, при этом сделал бы это всё используя подход фреймворка, и в слое самого приложения вообще бы не было разницы со стандартными методами броадкастинга. Чем в приложении автора пойму откуда какая переменная прилетела и откуда например на какой то строчке есть $user хранящая данные аутентифицированного пользователя. Не говоря уже о каких то сложных вещах типа нескольких одновременных аутентификациях.
А использования тысячи переключалок в визуальной утилите еще сложнее. Я бы быстрее код ядра фреймворка прочитал и понял.
Нет простоты у тебя автор. Никакой
поговаривают, что такие люди не программисты и для них cms есть.
А почему не jacquestvanzuydam/laravel-firebird? Я знаю чем он не нравится мне, но чем он не подошел вам?
fix:
Вы не правы. Не до конца разобрались. За непосредственно работу с подключениями отвечает
DatabaseManager implements ConnectionResolverInterface. Он уже в свою очередь используетConnectionFactory, которая содержет работу с встроенными (доступными из коробки) типами подключений. но стоит посмотреть на методmakeConnection(https://github.com/laravel/framework/blob/5.3/src/Illuminate/Database/DatabaseManager.php#L156-L177) Видим что тут есть проверка на наличие экстеншена, и только потом если его нет то идет обращение к стандартной фактори.т.е. у вас в коде сервис провайдера должно быть что то вроде
Серьезно? Это в каком информационном "коконе" вы прибывали что приведенные ссылки для вас оказались в новинку и вы теперь "думаете что делать". Неужели вы с 2012ого по 2016 (как указано на сайте вашего творения) не слышали о composer, PHP FIG и "постулатах" right way.
Или я не верно понял ваш комент...
Где то в своем скриптике тихо мирно выбрал я значит из бд пользователей в $users массив сложил. Потом надо мне их проитерировать, ну я и пишу
foreach ($users as $user)И всё сломал ибо вы такой умный и у вас$userэто глобал который хранит авторизованного пользователя.Да какая тут может быть критика. Критика это когда "Хм интересно, но я не согласен по паре пунктов." У вас же всё плохо. Нет, серьезно, нет ни одного файла, функции, да практически строчки кода которые были бы нормальными.
Килотонны пафоса зато. Мне сначала было забавно, но чем больше тут от вас комментариев и тем мне страшнее. "Чувак, да что блин с тобой не так?"
Но давайте попробуем "покритиковать". Давайте не будем затрагивать что то уровня использования ООП, eval и глобалы — зло. если с 2012 по 2016(а именно так стоит на сайте) вы не прочли те сотни материалов что существуют и ваша практика так же вам не показала что тут что то не ладно, то думаю в паре комментов мы так же ничего не проясним.
Поговорим о том, что ваш код нарушает ваши собственные тезисы и конвенции.
http://ru.coresky.net/article?standards
но при этом
с 12 префиксов!
или
И этому идеально следуют такие повсеместно используемые прям центральные глобалы
$skyи$userи многие другие (http://ru.coresky.net/code)Да что тут говорить если вы льете кучу пафоса и рассуждений вида
но открыв самое простое что обычно есть в проекте — точку входа index.php я очень долго искал откуда же там у меня $user
Это можно продолжать и продолжать. Еще раз, плохо ВСЁ.
Вариант с ограничением по константе не просто устаревший, он несостоятельный.
Вообще Вы что то мешаете всё в кучу. Начинался диалог с опровержения определения структурного паттерна. Давайте по пунктам.
1. То что в статье (какое бы оно ни было) это Декоратор. Он именно сохранил всё что умел предыдущий объект. И добавил то что тот не умел.
2. Нет это никакой не «паблик морозов» (хотя я вообще не уверен можно ли дискутировать про шуточный антипаттерн). Он не позволит обратиться к закрытым методам внутреннего объекта. Он им был бы если бы враппер (использовано в общем смысле) был бы наследником или того же класса что и внутренний объект.
3. В статье «презентор» не имеет отношения к MVP. Так же как и ваша попытка притянуть сюда архитектурный паттерн MVVM а точнее его часть ViewModel.
4. Стоит ли убрать магический call из конкретно таких презентеров? Да возможно стоит.