pronskiy Feb 22 2015 at 23:58

PHP-Дайджест № 57 – интересные новости, материалы и инструменты (9 – 22 февраля 2015)

4 min

22K

Zfort Group corporate blogWebsite development*PHP*

+29

Comments 25

Starche Feb 23 2015 at 00:36

Голосование закончилось с результатом 67 за и 34 против, а значит, не хватило всего одного голоса для его принятия. В связи с этим автор предложения Andrea Faulds, объявила о том, что прекращает работу над PHP

Прямо Rage Quit какой-то. Какой накал страстей. Жаль, что не приняли — отличная же затея. Только на Энтони вся надежда осталась, может его версию RFC доведут таки до релиза. С учётом ранее принятого RFC про типизацию возвращаемых значений получим почти полный комплект опциональной строгой типизации. И это прекрасно, я считаю. С удовольствием переберусь на PHP7 в продакшене, как только нужные расширения подтянутся (там же Extension API меняют, так что, видимо, придётся подождать некоторое время)

Fesor Feb 23 2015 at 00:57

На реддите последние две недели очень много писали на эту тему. В частности был еще предложение от Сары из фэйсбука, но вроде как товарисч Зив в весьма грубой форме попросил ее остановиться, мол его RFC лучше. Короче последние две недели php ветка рэддита бурлит ненавистью и непониманием действий zeev.

neolink Feb 23 2015 at 01:01

ну в целом Расмус по делу написал почему RFC в таком виде принимать нельзя, и я думаю многие согласятся что нерабочий tan(2) это просто жесть.

declare(strict_types=1) — зачем из php делать javascript? как это всё будет жить со сторонним кодом?!

Starche Feb 23 2015 at 01:07

многие согласятся что нерабочий tan(2) это просто жесть

Я не очень в курсе, как у них там всё происходит. RFC либо принимают, либо нет, возможности внести правки не существует, надо подавать новый RFC? Просто автоконвертация на входе int во float это весьма логично, и без неё, конечно, типизация неюзабельна.

Davert Feb 23 2015 at 01:45

и я думаю многие согласятся что нерабочий tan(2) это просто жесть.

а можно ссылку на эту часть дискуссии? Буду очень благодарен

neolink Feb 23 2015 at 08:11

прямо из статьи: plus.google.com/106194506269893913674/posts/WSknbzJPdqo

Fesor Feb 23 2015 at 02:00

1) Обсуждалось что если в стрикт режиме функция ожидает float и туда приходит int, то ничего страшного не должно происходить если не происходит потери данных при приведении типов.

2) по умолчанию код в режиме weak тайп хинтинга, так что это не особо проблема.

3) А что именно вас смущает? Уже тысячу раз говорилось что это все разруливается с вызывающей стороны. То есть если у вас сторонний код содержит функцию принимающую например строку, и файл в стрикт моде, то если ваш код написан в weak моде разницы для вас нет никакой. С точки зрения функции в сторонней библиотеке ей придет строка а не что-то другое (если конечно удается привести типы). А вызовы внутри этого стороннего кода уже будут строгими. Как по мне это нормальный компромис.

У расмуса очень много аргументов сводится к примерам кода из wordpress. Причем пишется все так будто бы разработчики вордпресов будут во всю использовать вообще тайпхинтинг для скаляров.

voidMan Feb 23 2015 at 12:45

Вообще она писала в твиттере, что это не столько из-за разногласий, а сколько из-за собственных проблем. Хотя возможно это просто дипломатическая отмазка :) Источник — twitter.com/AndreaFaulds/status/567267887657021440

gro Feb 23 2015 at 00:44

Предлагается добавить возможность указания нескольких типов для этих случаев, например:
function (array|Traversable $in) {}
Это круто, конечно.
Но конкретно в этом случае лучше бы включили array в Traversable и в ArrayAccess или отдельные псевдо-типы для этого сделали.

Fesor Feb 23 2015 at 00:59

Вроде как от этой идеи отказались и крайне негативно восприняли.

LastDragon Feb 23 2015 at 09:26

И правильно, не нужен еще один велосипед, всё давно решено через полиморфизм, который как раз будет очень кстати после принятия scalar type hints.

-1

gro Feb 23 2015 at 13:11

Это и есть полиморфизм.
Если я пишу:
function func($a) {
foreach ($a as $k => $v) {
//…
}
}
То мне всё равно, массив это или объект-итератор.
Сейчас нет возможности указать «я хочу здесь итератор и мне плевать, объект это или нативный массив».

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

LastDragon Feb 23 2015 at 13:20

Я говорил только про саму возможность указать несколько типов через "|". Насчет же массивов — их давно следовало переделать в объект, тогда и проблемы бы не было.

gro Feb 23 2015 at 16:18

Но тогда это был бы уже не похапэ. Если оставаться в рамках того, что есть, то "|" всё-таки какое-никакое решение.

Fesor Feb 23 2015 at 16:46

Кривое это решение. Но не думаю что раньше 8-ой веркии параметрический полиморфизм появится в пыхе. Что до «был бы уже не похапэ» — а может так будет лучше?

UFO just landed and posted this here

Fesor Feb 23 2015 at 10:36

Голосование не закончилось, его отменили за пару дней до. И да, из тех кто голосовал против — большинству не нравилась возможность объявлять блоки с declare или же сам синтаксис для declare. В v0.5 этой RFC есть подробное описание что зачем и почему было выбрано — так что я надеюсь что многие из тех кто голосовали против передумают. Так же частенько люди не понимали как будет работать эта мешанина из модов и их это смущало. Кто-то просто не хочет видеть стрикт тайп хинтинг в php и мотивирует это фразами типа «всеравно это никто не будет использовать».