Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

Смерть Yii

Вот смотрю в какую хорошую сторону двигается ПХП =)
Composer, PSR-0 и Dependency Injection.

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

И я вижу яркое будущее в том что PHP-FIG стандарты сделают код читабельным и легким для портирования.

И навеки умрет то подобия именуемое Yii на которое и смотреть противно в код

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Лучшие комментарии пропустить

Удалил все свои проекты на Yii

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

запарил со своим phpixie. шел бы лучше на хабре еще одну статейку написал, типа нейтральный пользователь, выбирал легкий php-фреймворк и выбрал свой же

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

не могу писать на хабре, поэтому пришлось здесь написать

С таким отношением я очень рад что вам на хабре писать не дают =) Хорошо там фильтруют

Какая экспрессия, какие эмоции :D

Смерть Yii — мне кажется , преждевремнное объявление — хотя мой PHP кастом департмент при слове Yii , добавляет букву Х. в начале

Зачем то тему оживлять? Ей уже огого сколько

И что автору «мега кодеру» со своим говно-велосипедом не понравилось в yii? аргументы, куда именно противно смотреть?

Просто перестаньте его кормить.

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

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

характерно в основном для пхп
на то есть причины. Нет в php открытых классов, как в руби. Поэтому разрыв зависимостей осуществляется через DI/service locator. А ioc контейнер — облегчение/уменьшение кода инициализации
Поэтому разрыв зависимостей осуществляется через DI/service locator.
Я так понимаю вы говорите о инверсии управления, собсно ее можно реализовать по разному в том числе и через DI.
А ioc контейнер — облегчение/уменьшение кода инициализации
Наверное контейнер всетаки не очень облегчает/уменьшает, судя по тому, что он пока особо не прижился за приделами Java/Net/PHP
Я так понимаю вы говорите о инверсии управления
скорее о первопричине
Наверное контейнер всетаки не очень облегчает/уменьшает, судя по тому, что он пока особо не прижился за приделами Java/Net/PHP
в этих языках облегчает/уменьшает

подивіться clojure й clojurescript і взірвіть собі мозок.

гм. цікаво — навіщо ви це сказали ?

ну раз людина судить, що пехапе — вершина програмістської думки (а не фрактал поганого дизайну, як дехто думає), то варто їй показати мову із кращим задумом й реалізацією. Імхо, звісно.

ви справді вважаєте що функціональні язики доречні для веб розробки ? :) ну-ну
я вже мовчу про дещо скромнішу спільноту та менший функціонал

А чому Ви думаєте що не доречні?
Звісно, те що менше коду можна скопіпастити із стековерфлоу — це великий мінус мови, тут я з Вами погоджусь.
Ви, як аргумент, наводите меншу функціональність мови — дуже спірне твердження. Оскільки Clojure — тюринг повна мова, тому говорити про меншу функціональність самої мови не дуже доречно, напевне Ви припустили, що для Clojure існує значно менше бібліотек і всілякого роду «фреймворків»? — Звісно їх менше ніж для пехапе, але в Clojure є потужна стандартна бібліотека, що в поєднанні із можливістю перевикористання фреймворків й бібліотек написаних на java(чи javascript, якщо ви використовуєте ClojureScript) заповняє прогалину, що Ви описали.
І на завершення, Ви можете ознайомитись із веб-фреймворками для Clojure, такими як pedestal.io чи github.com/http-kit , і можливо Ви почерпнете щось нове й вартісне.

що в поєднанні із можливістю перевикористання фреймворків й бібліотек написаних на java
тобто треба вчити джаву ?

ну і просто зауваження, по деталям, які мені впали в очі:
— роути треба прописувати руками . майже у всіх пшп фреймворках цього не потрібно
— дефолтні (як для жави) проблеми з масштабуванням
впевнений що ще є, але приклади дуже прості, тому цього не видно (усякі там MVC, Convention over configuration)

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

1) є clojurescript — реалізація clojure на javascript — маємо node.js і весь хіпстерський js стек
2) роути — я майже впевнений, що їх можна згенерувати якщо придумати й дотриматись якоїсь convention, ну чи використати якийсь middleware
3) щодо хаскеля — в хаскеля немає такого рантайма як в жави/жаваскріпта + різне бачення ідіоматичного хаскеля самими хаскелістами + високий поріг входження, тому його не так активно використовують.
І щодо масштабування — я б не був таким категоричним)

1) є clojurescript — реалізація clojure на javascript — маємо node.js і весь хіпстерський js стек
тобто крім жави треба вивчити і ноду ? :)
2) роути — я майже впевнений, що їх можна згенерувати якщо придумати й дотриматись якоїсь convention, ну чи використати якийсь middleware
от у тому то і проблема.
щодо хаскеля — в хаскеля немає такого рантайма як в жави/жаваскріпта + різне бачення ідіоматичного хаскеля самими хаскелістами + високий поріг входження, тому його не так активно використовують.
#clojure — 624
#haskell 1108
це людей на фріноді

Удалил все свои проекты на Yii

Не забудь потом переписать их все на PHPixie — д’Артаньян намекает и рекомендует...
xD

У меня еще опыта маловато такими серьезными вещами заниматься

Я вижу отличную бизнес-нишу для тренингов, вебинаров, мастер-классов и коучинга.

Да, можно целую конференцию забацать на тему «Лисапед мой, лисапед». Позовем ТС-а, Болген ОС и флешку — маркер!

Dependency Injection
Почти 10 лет в Java его используют, а у вас в php это только стало обыденной практикой?
статики, синглтоны и всякие другие анти-паттерны
Этого стараются избегать и в Java и .Net.
ПХПешка станет наверное первым
Ну ты понял.

Ну идея больше в фреймворках. С того что я видел на джаве то в фремворках статики еще те. ( Правда было это 5 лет назад)

Давайте поподробнее, что вы там видели?

Кажется фреймворк назывался tapestry. Деталей на вспомню,остался только осадок)

Дайте угадаю, легаси проект, скорее всего с древней версией tapestry. Про него впрочем ничего хорошего и сейчас не говорят, точнее никто им просто не пользуется.

Опять же, в топик реквестируются пруфы вышесказанного.

Dependency Injection

Почти 10 лет в Java его используют, а у вас в php это только стало обыденной практикой?

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

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

а как можно применять di в динамическом языке? ну или наоборот не применять его?
Вот это тролль! Нет это для меня слишком толсто.

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

У вас не правильное представление о типизации. Это все условности и не более.
PHP: типизация динамическая, но по сути только для примитивов. Нет кастинга одного объекта в другой, объектов и примитивов. Кстати есть абстрактные классы и интерфейсы.
C++: там вроде как типизация статическая, но при этом есть кастинги объекта в примитив, примитив в объект и объектов разных типов. То есть даже если у метода есть зависимость на какой-то тип, туда можно передать все что угодно
Python/Ruby/JS: там сильно, не парятся — просто ставят проверку (if)

то-есть вы хотите сказать, что в php для функции вроде
public function someFunc($someVar)
{
$someVar->anotherFunc();
}
кроме того, что someVar должна содержать метод anotherFunc накладываются еще какие-то дополнительные условия?

Не накладывают. DI что в динамическом, что в статическом языке позволяет вставить в качестве значения поля, параметра метода или конструктора значение выбранного вами типа. В динамическом языке тип вы не указываете, но и что с того? Все равно в одном случае у объекта может быть настоящий метод, который, там, в базу лезет или сервис дергает; а в другом случае — вставить мокк или стаб какой-нибудь, чтоб юнит-тесты проходили.

Почти 10 лет в Java его используют, а у вас в php это только стало обыденной практикой?
нет, это топикстартер открытие для себя сделал.

нет, это наконец фреймворки начали писать ровнее

И навеки умрет то подобия именуемое Yii на которое и смотреть противно в код

А можно примеры кода Yii, на которые противно смотреть, и примеры красивой реализации тех же фич в вашем фреймворке?

Вот смотрю в какую хорошую сторону двигается ПХП =)
Composer
Я так вижу ПХПешка станет наверное первым (поправьте меня если не так) языком где в кода не модно будет юзать статики, синглтоны и всякие другие анти-паттерны. Даже сами фреймворки уже не релевантны а фактически являют собой набор легкозаменимых компонентов.

Почему второе следует из первого? Композер кстати — древний баян, Gemfile и bundle install придумали за сто лет до композера.

Вот кусок кода Yii

public static function getPathOfAlias($alias)
{
if(isset(self::$_aliases[$alias]))
return self::$_aliases[$alias];
else if(($pos=strpos($alias,'.'))!==false)
{
$rootAlias=substr($alias,0,$pos);
if(isset(self::$_aliases[$rootAlias]))
return self::$_aliases[$alias]=rtrim(self::$_aliases[$rootAlias].DIRECTORY_SEPARATOR.str_replace('.',DIRECTORY_SEPARATOR,substr($alias,$pos+1)),'*'.DIRECTORY_SEPARATOR);
else if(self::$_app instanceof CWebApplication)
{
if(self::$_app->findModule($rootAlias)!==null)
return self::getPathOfAlias($alias);
}
}
return false;
}

Вот мой фремворк ( core классы, теперь пикся все разделена как симфони) github.com/...ny/PHPixie-Core

Посмотрите сами. От кода Йии глаза плачут кровью

Чем конкретно не нравится этот кусок кода, и как он должен выглядеть, по вашему?

1) ну для начала я б self::$_aliases записал в переменную, а то копи паста.
2) конструкция if() {return;}else{} глупа до немогу (особенно когда их несколько еще), зачем там елс ? И так ретурн остановит.
3) почему она возвращает false, который булеан, должно быть null
4) Доу обрезал по длинне 10 строку, она в 3 раза дольше!!! нужно скролить в редакторе! почему не разбить логику на 2 рядка?
5) Уйма точек выхода
6) все статики! как тестировать?
7) Почему self а не static ? как екстендить?

Удивлен что вы не заметили ничего из этого

7) Почему self а не static ? как екстендить?
А для чего формошлепу тестить и экстендить Yii::Base?
3) почему она возвращает false, который булеан, должно быть null

Почему должно быть null, а не false?

2) конструкция if() {return;}else{} глупа до немогу (особенно когда их несколько еще), зачем там елс ? И так ретурн остановит.

Опять же — предлагайте свой вариант. А еще лучше — коммитните его.

А для чего формошлепу тестить и экстендить Yii::Base?
Не все в мире формошлепы! Я кстати например =)
Так вот а что делать если что-то захочете поменять? тот же симфони да и фьюлпхп позволяю это!
Почему должно быть null, а не false?
Учите матчасть =) Функцыя должна возращать путь к фалу (тоесть стринг). Если пути нет, то как раз для того и придумали null. False совсем другой тип! Вспоминаю одного коллегу который в функцию которая возвращала масив дописал чтоб она возвращала фолс если он пуст! Надо уметь типизтровать данные, как потом такое документровать?

www.yiiframework.com/...api/1.1/YiiBase
Почему-то false не мешает писать документацию к фреймворку в целом и к сабжевому классу в частности.

www.yiiframework.com/...doc/api/1.1/Yii
И даже наследоваться можно \о/

Надо уметь типизтровать данные, как потом такое документровать?

php.net/...comparisons.php
null значит «пусто», false значит «не вышло». В нашем случае не путь пустой, а «не вышло», потому false — все вполне логично.

Пока что все это выглядит как пук в лужу человека, чей код ни разу не лучше (dou.ua/...ums/topic/6733 напомнить?) и попытка пиара своего велосипеда/опускания ненавистного фреймворка с ненавистным скаффолдом.

Не вишло тогда надо ексепшн а не возвращать другой тип.
Именно из за такой логики как у вас на пхп грузят что оно кривое. Кае может ф-я такое делать?

А что скажете по поводу других пунктов, а то у вас коменти толко к двум нашлись.

По вашему строчка кода на полтора екрана тоже норма?

Конечно, невозможность вернуть путь к файлу — повод бросать эксепшен, о да :)

Остальные пункты относятся к стилистике кода, и да, я могу понять и self::$_aliases ($_aliases это ж переменная) — более читаемо, и якобы на полтора экрана строку (в мой экран влезает свободно).

public function __construct($pixie, $route, $method = «GET», $post = array(), $get = array(), $param=array(), $server = array())
{
$this->pixie = $pixie;
$this->route = $route;
$this->method = $method;
$this->_post = $post;
$this->_get = $get;
$this->_param = $param;
$this->_server = $server;
}

Мне например вот этот конструктор не нравится с 7 параметрами на входе. Ту зе форумс!

Учите матчасть. ) как раз хороший конструктор, все легко тестируется)

Реквестирую цитату из матчасти, которая предписывает подачу 100500 параметров в конструктор. Если открывать на гитхабе, в экран не влазит кстати. Предрекаю смерть фреймворка -.-

throw new \Exception("Route {$matched} matched with controller {$params['controller']}, but no action was defined for this route", 404);

А еще похапе умеет разносить строки, которые «невлазятвэкран!!!», на несколько строк.

Ну там же сообщение просто. Читая код даже не обратите на него внмания. В то время в йии там логика и операции которые надо прочесть

return self::$_aliases[$alias]=rtrim(self::$_aliases[$rootAlias].DIRECTORY_SEPARATOR.str_replace('.',DIRECTORY_SEPARATOR,substr($alias,$pos+1)),'*'.DIRECTORY_SEPARATOR); 

Ок, разнесем построчно

$path = self::$_aliases[$rootAlias];
$path .= DIRECTORY_SEPARATOR;
$alias = DIRECTORY_SEPARATOR,substr($alias,$pos+1));
$path .= str_replace('.',$alias,'*'.DIRECTORY_SEPARATOR);
Стало нечитаемо, не считаете ли?

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

Имхо бред в код фреймворка пихать примеры строк оО дока для чего?

Вспоминаю одного коллегу который в функцию которая возвращала масив дописал чтоб она возвращала фолс если он пуст!
Я целый проект так написан видел. Это был ад из ифов :)

if (someCollection != null) {
for (Foo c : someCollection) {
...
}
}
Учите матчасть =) Функцыя должна возращать путь к фалу (тоесть стринг). Если пути нет, то как раз для того и придумали null. False совсем другой тип! Вспоминаю одного коллегу который в функцию которая возвращала масив дописал чтоб она возвращала фолс если он пуст! Надо уметь типизтровать данные, как потом такое документровать?
лолшто??? в php сотни функций которые возвращают string или false и в этом нет ничего плохого, если об этом говорится в документации. точно так же нет никакой разницы, будет это null или false для конкретно этой функции, она либо вернет непустую строку (читай true) либо что-то другое. учи матчасть короче и не пиши херню. а лучше статью напиши как ты phpixie выбираешь среди других фреймворков.

NULL в концепции програмированния может быть значение любого типа (кроме скаляров). То есть он представляет пустоту и не несет в себе другой тип как например false который точно не стринг. В ПХП функции со стрингами возвращают false, потому что они скопированы из стандартной библиотеки Си ( в которой нет ООП). Если вы пишете ООП код, то следуйте best practices ООП. Другие языки (джава например) попросту не позволят вам возвращать то ли стринг то ли булеан. Я конечно понимаю что ПХП не Джава, но ООП есть ООП и нефиг писать говнокод.

Насчет ПХПикси есть тут довольно много: habrahabr.ru/...arch/?q=phpixie

ну ка, ссылочку в студию на "

best practices ООП
" и методы, возвращающие string, которые не должны возращать false

Ну вот тут пост Фила Стерджена ( член PHP-FIG, и один из мейнтейнеров phptherightway.com ) в котором он в деталях объясняет почему надо использовать NULL в пхп:
ellislab.com/...ewthread/215833

В других языках (Джава, Шарп) использовать что-то кроме нула не получится в принципе.

там вообще-то разговор идёт о сохранении данных в бд. но где говорится, что использование NULL является правильным для методов, возвращающих string и где говорится, что это best practices в ООП?

Сохранение в БД только один из примеров.
Посмотрите сюда www.phptherightway.com
например на реализацию синглтона, ві нигде там фолсов не увидите

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

Это не другие миры. Если вас послушать так давайте тогда использовать ’korova’ вместо Null и false. Синглтон на «коорове» тоже работать будет.

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

1) ну для начала я б self::$_aliases записал в переменную, а то копи паста.
про память ты не подумал?
2) конструкция if() {return;}else{} глупа до немогу (особенно когда их несколько еще), зачем там елс ? И так ретурн остановит.
наверное затем, чтобы потом в неё не забыть что-то списать. не?
4) Доу обрезал по длинне 10 строку, она в 3 раза дольше!!! нужно скролить в редакторе! почему не разбить логику на 2 рядка?
что ж поделаешь, если у тебя экран маленький
в остальном согласен с Elena Morgun

Кинул ванили на вентилятор.

Головна проблема РНР це дуже низька планка входу. Армія бидлокодерів попортила йому репутацію на довший час. Всі дитячі проблеми, про які мені розподіють «хтось десь почув».

Проблема в неправельному використанні інстурментів. Давайте згадаємо, що РНР виріс з шаблонитизатора і вся його архитектура не дає нам про це забути. Не треба писати мега-круті аплікації, де при кожному заході піднімається сотні інстансів. РНР не та мова, де треба старатись писати кравий, обєктно орієнтований код. Тут треба думати по іншому.

А при чому тут Yii я не розумію. Фреймворк надійний і легкий. Зараз вот нова версія готується. Зараз вот Сімфоні новий вийшов, кажуть що взагалі бомба.

Вроде все правильно написано. Действительно, кучу говнокода можно объяснить низким порогом вхождения и недостатками языка. Вот только, если посмотреть в по сторонам, то у тех же Java/.Net кучи ведь не меньше...

Головна проблема РНР
в том что много идиотов, которые пишут всякое фуфло вроде phpixie, форсят это с считают что правы
И навеки умрет то подобия именуемое Yii на которое и смотреть противно в код
Противно — не смотри, делов-то...
Запятых отсыпать?
А то на вброс очередного школоло по стилю очень похоже...

php имеет преемущество на шаред хостинге, 400 сайтиков на одном сервере фуле. А если VPS то нафик это счастие, есть же python.

ioc в каком либо виде, а тем более di в динамическом языке, где в принципе не может быть high coupling разве не оверкилл?

Каплінг может быть везде и всегда =)
Как и везде это статики + вызовы new по 10 раз в каждом методе. Если метод создает сам 10 инстансов разных классов, вот и каплинг.
Зато как раз в динамическом языке делать все это гораздо проще, так как не надо формально оглашать интерфейсы если не хочется)

это называется low coupling. фактически зависит только от интерфейса. и это нормально.
единственное преимущество от использования какого-нибудь ioc контейнера разве что выбор стратегии инстанциирования в отдельном модуле, а не в имплементации. И то не знаю на сколько это актуально

стандарты сделают код читабельным и легким для портирования
Заодно пусть поменяют всю кашу с наименованиями в стандартной либе
И навеки умрет то подобия именуемое PHP на которое и смотреть противно в код
Так было бы лучше

Ну тут нужно отличать ПХП само от того что на нем написано.
О каше в самом ПХП спорить не стану =)
Но радует то куда движется сообщество. Все-таки каша в самом коде мотивирует писать ровнее =)

Все-таки каша в самом коде мотивирует писать ровнее =)
И сколько таких? Процентов 10 ?

Подписаться на комментарии