Комментарии 60
RFC: Short Closures — В PHP 7.1 предлагается реализовать короткий синтаксис для анонимных функций
Вот не могу понять зачем это нужно? Глазами ведь выцепить такое при чтении кода будет в разы сложнее.
Нужно — сейчас слишком многословно получается, но вот тильда?! *рука лицо*
Ну сейчас по-крайней мере анонимная функция при её описании выглядит как функция. А вот это '~>' — сахар ради сахара?
Раздел с описанием предлагаемого синтаксиса — настораживает. Получится такая же шаурма со стилем именования функций PHP, за что его ругают, но только теперь — с новым синтаксисом.
Теперь — банановый.
Раздел с описанием предлагаемого синтаксиса — настораживает. Получится такая же шаурма со стилем именования функций PHP, за что его ругают, но только теперь — с новым синтаксисом.
Теперь — банановый.
У меня возникает только один вопрос, почему нельзя использовать комбинацию "->" вместо "~>".
Убогий парсер. Из-за этого практически все новые синтаксические конструкции вводятся с помощью новых ранее не используемых символов (пространства имен, например), а т.к. "->" уже занято, то выбрали свободную тильду (минусующий, как её набирать то?).
У вас очень правильное замечание. Мне кажется следует использовать правило как в других языках — больших анонимок лучше использовать полное function, а для однострочных ~>
В примерах есть usort($array, ($a, $b) ~> $a->val <=> $b->val);
usort($array, function($a, $b) { $a->val <=> $b->val; }); — PSR этот код просит разнести на пару строк из-за {}
В примерах есть usort($array, ($a, $b) ~> $a->val <=> $b->val);
usort($array, function($a, $b) { $a->val <=> $b->val; }); — PSR этот код просит разнести на пару строк из-за {}
PSR-7 уже на повторном голосовании. Проходит с перевесом.
А оно кому-то вообще нужно? Особенно учитывая что они сами пишут что практически все существующие библиотеки не используют value object…
Всем нужно, это первый шаг к тому чтобы в итоге библиотеки были заточены не под фреймворки а под php в целом.
На самом деле да:
1. Изолируют request/response практически все современные фреймворки, но делают это каждый по своему.
2. value object не нужен до тех пор пока мы не начнём использовать что-то вроде reactphp.org или daemon.io. Они всё более популярны. Знаю человека, который запускал по такому принципу Yii в продакшне.
1. Изолируют request/response практически все современные фреймворки, но делают это каждый по своему.
2. value object не нужен до тех пор пока мы не начнём использовать что-то вроде reactphp.org или daemon.io. Они всё более популярны. Знаю человека, который запускал по такому принципу Yii в продакшне.
2. А там вроде уже не настоящий value object — в последней версии разрешено возвращать $this из with* если оно не привело к изменению значения, интересно, какие из with* методов подходят?
Разве возврат того же инстанса в случае не изменения значения противоречит value object?
Как/кем определяется изменилось значение или нет?
Классом, реализующим интерфейс. Скорее всего, все будут делать так:
if ($this->something === $newValue) {
return $this;
}
Вот, только это значит что в разных реализациях вполне может оказаться что изменение внутренностей не будет создавать клон. Утрируя: ну вот решил автор что при изменении заголовков сам запроса не меняется, а сама библиотека при этом офигенно-офигенная и нужна в нашем древнем проекте просто позарез — привет цепочки, привет отладчик, прощайте выходные… Если уж решили создать свой 15 стандарт с блекджеком и ..., то надо было делать максимально однозначно.
Я вот ещё смотрю на RingPHP, который под капотом Guzzle 5+ — тоже вроде какая-то абстракция над HTTP. Как это всё соотносится?
PSR сделан теми же людьми, см. member projects. На него со временем большинство там упомянутых перейдут.
Вообще PSR-ы пишутся бег оглядки на существующие реализации. На будущее.
Вообще PSR-ы пишутся бег оглядки на существующие реализации. На будущее.
github.com/davispeixoto/PHP-Batch — классы все пустые.
Замкание всей области видимости в функцию — это, мне кажется, слишком не «php way». Появятся проблемы с производительностью и циклическими ссылками, которые ещё не готовы решать.
10 вещей про симфони признано экстремистским материалом.
Фабпот подсуетился.
Фабпот подсуетился.
Замкание всей области видимости в функцию — это, мне кажется, слишком не «php way». Появятся проблемы с производительностью и циклическими ссылками, которые ещё не готовы решать.
полностью согласен с оратором. никогда этого не было и то что в майнтенерах пхп появилось несколько «ужаленных» которые пытаются тащить из скалы, ерланга, хаскела и при этом тащить просто какие-то фишки это плохо
вот новое ядро — это хорошо.
если уж захотелось сделать покороче… то простой почти безболесненный способо это сделать ввести алиас для function — например fun
но этж ну вообще не главное!
надо думать о развитии SPL!!!
полностью согласен с оратором. никогда этого не было и то что в майнтенерах пхп появилось несколько «ужаленных» которые пытаются тащить из скалы, ерланга, хаскела и при этом тащить просто какие-то фишки это плохо
вот новое ядро — это хорошо.
если уж захотелось сделать покороче… то простой почти безболесненный способо это сделать ввести алиас для function — например fun
но этж ну вообще не главное!
надо думать о развитии SPL!!!
С чего вы взяли, что такая фишка есть только в скале, ерленге и хаскеле. Короткий синтаксис есть в C#, Java 8, C++, Dart, JavaScript (ES6), Perl6, Groovy, Python, Swift и еще во многих языках. Он полезен и удобен, особенно во всяких event-подобных штуках.
Замыкание скорее всего будет производится не всей области видимости, а только тех переменных, которые используются внутри функции, главное чтобы разработчики php верно реализовали это.
Замыкание скорее всего будет производится не всей области видимости, а только тех переменных, которые используются внутри функции, главное чтобы разработчики php верно реализовали это.
надо думать о развитии SPL!!!
И в первую очередь — о его производительности. SPL-итераторы — очень интересная вещь, но тормоза в 7 раз по сравнению с обычными циклами — это жуть.
Итераторы обычно нужны для экономии памяти, для ленивых операций над коллекциями. В задачах где требуются итераторы тормоза в 7 раз не делают погоды. Цепочка итераторов способна творить чудеса по производительности, как пример Stream API из Java 8.
Ну вот у меня есть задачи, где использование итераторов значительно сократило бы и объем кода и его читаемость, но я вынужден был отказаться от них именно из-за тормознутости.
Так в том-то и дело, что речь о реализации SPL-итераторов в PHP
… как пример Stream API из Java 8
Так в том-то и дело, что речь о реализации SPL-итераторов в PHP
В любом случае, итераторы нельзя сделать быстрее, они никогда не смогут работать быстрее обычного цикла или с такой же скорость. Это объекты, вызовы методов, поднимается стек вызовов и на все это затрачивается время. Я думаю итераторы можно немного оптимизировать по скорости выполнения, но не намного.
PHPPm и хостингер не выдержали хабраэффекта
Поменял ссылку на гитхаб github.com/PHPPm/phppm
Лучше вместо короткого синтаксиса анонимных функций сделали бы что-то похожее на stream API в java 8 www.deadcoderising.com/java-8-no-more-loops, только нативное, кстати вот реализация в одном фреймворке ouzo.readthedocs.org/en/latest/utils/functions.html#extract
НЛО прилетело и опубликовало эту надпись здесь
Быть. Уверен. Новые штуки выходят с использованием всего и я бы не стал утверждать, что новых штук на PHP не выходит, это всё-таки 82% всего веба.
82% от количества проектов, а не от количества посещаемости этих проектов. Миллион проектов на вордпресе и других cms делают эту статистику, но это же не значит, что в этих проектах участвует программист. Если бы можно было бы посчитать процент проектов, в которых участвовал программист, то это была бы справедливая статистика.
М… хабр, Yahoo, Facebook, Wikipedia, Flickr, Digg, SourceForge, Вконтакте, mailchimp, Etsy, Zynga. Мало? Могу ещё.
PHP is used by 82.0% of all the websites whose server-side programming language we know.
Пишут, что от количества сайтов. Facebook -> Google, Microsoft, Bing, SourceForge -> Github, Bitbucket, Вконтакте -> Одноклассники, Twitter, можно приводить бесконечное число известных крупных проектов сделанных не на php. Поэтому я написал, что берут они от количества, т.е. любая минимальная страничка сделанная на php +1 к этому рейтингу.
Конечно они считают количество. Посещаемость мало кто отдаёт. И всё-таки, я считаю, что такая метрика популярности довольно справедлива. Ничто не мешает делать мелкие проекты на том же Python или Ruby или Perl… на чём угодно. Но почему-то они не популярны для этих целей. В то же время, сверхкрупные проекты на PHP делаются и успешно.
Я не утверждаю, что PHP очень хорош как язык, но он развивается, он отлично подходит для веба, лучше, чем остальные, и будущее у него определённо есть. Даже если он умрёт, то медленно и не скоро.
Я не утверждаю, что PHP очень хорош как язык, но он развивается, он отлично подходит для веба, лучше, чем остальные, и будущее у него определённо есть. Даже если он умрёт, то медленно и не скоро.
НЛО прилетело и опубликовало эту надпись здесь
Websockets чатик на пхп делается не сложнее чем на любом другом языке socketo.me/demo
Что позволяет вам делать подобные заявления?
То, что он работает везде, есть у каждого, даже самого ужасного хостера, заводится с пол пинка, кушает код практически любого качества и имеет тучу готовых и полуготовых решений.
Потому что именно на нём сделали Wordpress и у него были конкуренты под .NET и Java точно, но вот не взлетели из за гемора с развёртыванием и хостингом. То же про Drupal, Joomla и т.д.
Вебсокеты — не подавляющее большинство проектов. Я бы даже сказал, что довольно редко нужны. Ну и не вижу особых проблем с ними работать из PHP. Конечно, сразу всплывают требования к окружению, но они сходные и в случае Python или Ruby.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Знаю на тему Yahoo. Они бы так и использовали PHP для фронта. Также знаю проекты, где сайт (то есть CMS, всякие формы фидбека и т.д.) делается на PHP, а продукт на Java. Причём изначально делалось всё на Java и впоследствии сайт был переписан на PHP. Причины — не надо билдить, правки вносить быстрее, это может делать менее дорогой сотрудник, найти и заменить которого значительно легче.
Ещё могу сказать про наш stay.com. Также делали бы на PHP, хотя отдельные части у нас бегают на go, а приложения, естественно, на Java и ObjectiveC.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP-Дайджест № 62 – интересные новости, материалы и инструменты (26 апреля – 11 мая 2015)