pronskiy 27 янв 2019 в 21:40

PHP-Дайджест № 148 (14 – 28 января 2019)

4 мин

15K

Laravel * PHP * Symfony * Yii * Веб-разработка *

+65

Комментарии 26

affka 28 янв 2019 в 03:19

yii теперь только в тегах… (

marad3r 28 янв 2019 в 05:42

Все к этому шло, к сожалению. А может быть и к счастью, все больше людей будет обращать внимание на лидеров рынка.

xRay 28 янв 2019 в 09:59

Все новости тут github.com/yiisoft/yii-core/commits/master github.com/yiisoft/yii-core/milestones

Как раньше написал SamDark

Жив. Основные части 3.0 уже можно даже запустить. Но пока там много работы, не хотим раздувать новостей из ничего…

habr.com/ru/company/zfort/blog/426391/#comment_19238099

Информация о структуре пакетов в yii3 github.com/yiisoft/docs/blob/master/000-packages.md#yii-framework

UksusoFF 28 янв 2019 в 06:33

Про EAP Шторма забыли? :) Обычно вроде пишете.

pronskiy 28 янв 2019 в 07:01

Да :-) добавил, спасибо!

rjhdby 28 янв 2019 в 07:08

[RFC] Code free constructor

Резиденты internals настроены скептически, а жаль.

SerafimArts 28 янв 2019 в 07:38

Репозиторий PEAR был взломан — Сайт pear.php.net ушел в офлайн и не работает до сих пор.

Хм, а кто-нибудь этим PEAR вообще пользуется? По-моему он уже давным-давно и так помер.

rjhdby 28 янв 2019 в 07:46

Там есть полезные расширения. Например для работы с редкими/экзотическими базами данных.

SerafimArts 28 янв 2019 в 07:49

Эм, а вы на счёт расширений с PECL не перепутали? PEAR — это как композер, только неюзабельный, древний, и как оказалось — дырявый =)

P.S. Ой, случайно в вашей ветке ответил, не заметил. То что выше в 10:38 — это не комментарий к вашему, а к посту самому коммент.

rjhdby 28 янв 2019 в 07:53

Посыпаю голову пеплом! Аббревиатуры — такие аббревиатуры.

molchanoviv 28 янв 2019 в 08:36

Этот RFC как минимум не доработан. Там в качестве проблемы указана перезапись родительской переменной, но ведь это давно решено например в Kotlin если используется модификатор доступа, то это поле класса, а если нет, то локальный параметр используемый только в конструкторе. Такая-же история и с анонимными классами. Отсюда и скепсис. Никто не хочет внедрять полурабочую фичу.

rjhdby 28 янв 2019 в 09:07

Не совсем так. Что Никите Попову, что Себастьяну Бергману не нравится именно предложенный синтаксис.

> I think that *if* we want to add some kind of sugar of this type, then I'd
> strongly prefer the syntax used by Hack than the one proposed here.
Agreed.

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

PS С другой стороны, дискуссия про изничтожения бойлерплейта в конструкторе в принципе завязалась, что хорошо :)

berezuev 28 янв 2019 в 07:44

xobotyi/php-mime-type — Библиотека позволяет определить MIME-тип по расширению.

Не нужно так делать. С такой проверкой можно любой бинарник обозвать *.jpeg и свободно загружать на хостинг. А ведь все уже давно изобретено.

gro 28 янв 2019 в 12:25

А зачем давать возможность запускать jpeg?

xobotyi 28 янв 2019 в 21:18

Никто не предлагает определять майм-тип по расширению, первоцель обратная — узнать известные расширения по майму.
UPD: перечитал какое описание поставли… вводит в заблуждение…

NickyX3 29 янв 2019 в 05:50

Я вас расстрою, указанная mime_content_type делает тоже самое, юзает mime.magic файлик, никакие сигнатуры не тестятся.

screamer_gi 28 янв 2019 в 09:23

Zeev Suraski и команда Zend в лице Дмитрия Стогова, Enrico Zimuel и Matthew Weier O'Phinney в скором времени покинут Rogue Wave (владеет Zend)

Компания Perforce поглотит Rogue Wave Software

Это как-то связано?

rjhdby 28 янв 2019 в 10:00

Кстати, немного интриг, скандалов и расследований(с) вам в статью. :)
Коммит от 24 января сего года проскочили такие изменения:

-   | Authors: Andi Gutmans <andi@php.net>                                 |
-   |          Zeev Suraski <zeev@php.net>      
+   | Authors: Andi Gutmans <andi@zend.com>                                |
+   |          Zeev Suraski <zeev@zend.com>

tendium 28 янв 2019 в 13:54

Не знаю, как вас, а меня сильно смущает магия в PHP RFC: Code free constructor, связанная с именованием аргументов конструктора (автор, кстати, сам подметил одну из проблем: Child constructor will silently rewrite parent's properties with same name). Это, имхо, прямой путь к неочевидным и трудно находимым багам. Да и вообще сам RFC выглядит каким-то недоработанным. В частности, не раскрыта тема (или я слепой) на счет областей видимости полей объекта. Не раскрыта и тема о поведении парсера/компилятора в случае приватных полей, имеющихся как у родителя, так и потомка. А что на счет отсутствия поля у объекта? Оно будет неявно объявлено как public? Или?

P.S. Ясно, что всё это можно теоретически вычитать из PR, но разве это не первичная задача для технической документации?

rjhdby 28 янв 2019 в 18:03

Ясно, что всё это можно теоретически вычитать из PR, но разве это не первичная задача для технической документации?

Ну, вообще-то, на странице с предложением есть ответы на большинство ваших вопросов.

By the way, current realization simply add “_ _construct” method into class via AST injection. Another words, code “($cc, $whells)” considered as zend_ast node “parameter_list” and accordingly processed by standart way. You can declare property type like you declare them inside standard method. Also you can declare defaults for parameters, use “…” notation (there is a nuance) and do everything else.

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

PS А вообще странно, что его в статью включили, так как это черновик на этапе самого первичного обсуждения и понятно, что вопросов еще много. А тут сразу критиков понабежало и ну давай автора расстраивать :D

pronskiy 29 янв 2019 в 09:06

Интересные черновики всегда включаю. А критика это ж хорошо – быстрый фидбек от реальных пользователей PHP и возможность подправить RFC.
А вы не проводили анализ GitHub/Packagist на предмет того, насколько часто такой бойлерплейт код используется?

rjhdby 29 янв 2019 в 09:34

А вы не проводили анализ GitHub/Packagist на предмет того, насколько часто такой бойлерплейт код используется?

Нет, оценивал субъективно и, честно говоря, большей частью не по PHP-коду, а по JVM-языкам. Исторически сложилось, что там гораздо чаще смотришь чужой код.
Откровенно говоря, одним из скрытых побудительным мотивов было желание подтолкнуть разработчиков к этой практике. Эдакая завлекалочка — «теперь ты можешь сделать код лучше, написав меньше». :)
Понятно, что про «лучше» в этом контексте — это только одна из точек зрения. Многие согласятся, многие нет. Вот для тех, кто согласится, жизнь станет легче.

rustacean137 2 мая 2023 в 07:13

А вы не проводили анализ GitHub/Packagist на предмет того, насколько часто такой бойлерплейт код используется?

Да, часто используется.
Но решение в RFC не понравилось, из за возможных неочевидностей.
Почему бы не сделать как в TS?

<?php

class Foo
{
    public function __construct(private $bar) {}
}

rjhdby 29 янв 2019 в 12:19

В частности, не раскрыта тема

Постарался раскрыть

NickyX3 29 янв 2019 в 05:51

leocavalcante/siler — Микрофреймворк реaлизован на простых функциях без использования классов. Можно использовать со Swoole

Забавная штука, очень забавная, прямо заинтригован

Compolomus 29 янв 2019 в 08:56

Хорошие новости. Ожиотаж вокруг php все же есть. Плохо конечно что команда дробится, но то что будет финансирование уже хорошо

Зарегистрируйтесь на Хабре, чтобы оставить комментарий