iGusev25 янв 2015 в 21:10

Революция PHP7: Типы возвращаемых значений и удаление артефактов

5 мин

55K

PHP *

Перевод

+41

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

SerafimArts 25 янв 2015 в 21:57

Если уж говорить о перспективах, так как об апи не было ничего сказано, то оное в jphp почти что идеально в той перспективе, в которой следует двигать оригинал. Яб точно не отказался увидеть это в будущей версии пыха.

Arilas 25 янв 2015 в 22:40

Return Types долго ждал, понравилось как было сделано в первой версии RFC, которую забраковали, исправили это поведение так:

interface A {
    static function make(): A;
}
class B implements A {
    static function make(): B { // must exactly match parent; this will error
        return new B();
    }
}

Вот из-за этого поведения, return_types не будет использоваться активно. К примеру в Hack можно указать тип возвращаемого значения как 'this', то в текущей реализации в PHP этого сделать будет нельзя. В итоге люди все равно будут дальше использовать обычный phpDoc: @ return $this для этих целей, и IDE будет работать правильно.

Если бы хотя бы добавили Генерики, было бы намного проще:

class AbstractRepository<T> 
{
    public function find($id): ?T
    {
        ...
    }
    ....
}

Так было бы намного удобнее это сделать (к примеру так сделано в Hack);

Arilas 25 янв 2015 в 23:14

Немного объяснений:
У вас есть ваша любимая ORM'ка (к примеру Doctrine), у которой есть AbstractRepository, который используется как репозиторий по умолчанию, и также вы от него можете насследоваться. У этого AbstractRepository есть метод find, который возвращает нам объект Entity. Представим, что все Entity реализуют интерфейс EntityInterface, тогда наш AbstractRepository будет иметь вид:

class AbstractRepository 
{
    public function find($id): EntityInterface
    {
        ...
    }
    ....
}

Вроде все правильно, find действительно возвращает EntityInterface, но если мы будем использовать его для определенной Entity, к примеру User, мы не сможем при наследовании переопределить тип возвращаемого значения как User, то-есть такой код приведет к Fatal Error:

class UserRepository extends AbstractRepository 
{
    public function find($id): User
    {
        ...
    }
    ....
}

То-есть нет сужения/расширения классов, возьмем к примеру Java:

public interface A {
    public A create();
}
...
public class HelloWorld implements A
{
     public static void main(String []args){
        HelloWorld a = new HelloWorld();
        a.create();
     }
     
     public HelloWorld create() {
         return this;
     }
}

Такой код является валидным, так как он не противоречит условию.

Fesor 26 янв 2015 в 00:52

В вашем примере есть еще одна проблема — make всегда должен возвращать B. То есть тот же пример с find у абстрактного репозитория с
nullable types в draft-е лежит уже, без него смысла лепить это дело на методы типа find сами понимаете мало. В целом же пример с абстрактным репозиториями я лично считаю надуманным.

SerafimArts 26 янв 2015 в 01:08

Имхо — подобный драфт не совсем практичный, намного удобнее было бы унифицировать аргументы для получения нескольких значений, например вот таким образом:

public function some(SplFixedArray|null $any) 
{
}

Это позволит не только определять аргумент, как nullable, но и указывать несколько типов аргументов. Хотя вариант с перегрузкой был бы всё же красивее…

Fesor 26 янв 2015 в 02:13

ну во первых подобный синтаксис есть и в java и в c# и используется оно по прямому назначению, разрешает использование null как значение. ваш вариант кроме того что выглядит ужасно, так ещё и убивает весь смысл тайпхинтинга. Если ваши методы/функции работают с разными типами то и тайпхинтинг вам не нужен.

SerafimArts 26 янв 2015 в 09:18

Так реализовано в TypeScript — по-моему это лучший вариант при наличии типизации в аргументах, но отсутствия перегрузки. Хотя с другой стороны может вы и правы и вполне достаточно хинтинга в автодоках для подсветки и разруливания типов в иде.

MaximChistov 26 янв 2015 в 07:47

не имеет смысла при крайней нестрогой типизации php, имхо…

SerafimArts 26 янв 2015 в 09:20

Я бы сказал не «крайне нестрогой», а «опциональной». Т.к. при желании можно писать почти так же, как на джаве (используя строгие spl-типы, например).

SerafimArts 26 янв 2015 в 13:48

Кстати на счёт «крайней нестрогости». Вот такое будет работать везде:

Пример (Чур в обморок не падать)

<?php
$i = int(23.0);
$f = float("asdasdasd");
 
class Test
{
    public static function printInt(int $i)
    {
        echo $i . "\n";
    }
 
    public static function printFloat(float $i)
    {
        echo $i . "\n";
    }
}
 
 
Test::printInt($i); // 23
Test::printFloat($f); // 0.0

А вот реализация

<?php
abstract class number
{
    protected $value;
    public function __construct($val)
    {
        $this->value = $val;
    }
 
    public function __toString() { return (string)$this->value; }
}
 
class int extends number
{
    public function __construct($v) { parent::__construct((int)$v); }
}
class float extends number
{
    public function __construct($v) { parent::__construct((float)$v); }
}
 
function int($v) { return new int($v); }
 
function float($v) { return new float($v); }

sferrka 26 янв 2015 в 14:01

Все бы было круто, если бы

echo $i + $f;

или

if ($f)
{
	echo $f;
}

после этого работало) А так бесполезно…

SerafimArts 26 янв 2015 в 14:16

не спорю, осталось дождаться ассепта вот этого: wiki.php.net/rfc/object_cast_to_types =)

Fesor 26 янв 2015 в 15:51

Скорее эту примут, чем драфт 3-х летней давности.

SerafimArts 26 янв 2015 в 16:56

По-моему эти rfc несколько разной направленности.

По моей ссылке позволяет нормально приводить объекты к другим типам, как следствие:
1) позволяет обходить такие проверки, как is_array при реализации объекта с интерфейсами ArrayAccess и проч.
2) позволяет выполнять математические операции, какое-нибудь сложение специфичных объектов, например векторов (Vector2), хотя с этим придётся помучаться, т.к. получение слагаемых вроде бы не предусмотрено
3) и уже в последний момент для подобной откровенной издёвки над языком, как я привёл выше, в качестве реализации строгой типизации

По вашей же ссылке — вполне очевидный рфц, добавляющий типы для скаляров (за исключением массива, т.к. он уже есть) и предназначенный только для этого. Т.е. перспектива очевидна и «унитарна», если так можно выразиться.

Fesor 26 янв 2015 в 17:08

По моей ссылке, вменяемый свежий RFC решающий конкретные проблемы. Возможность же каста объектов в скаляры штука весьма неудобная и создает почву для говнокода. Все эти эмуляции перегрузки операторов вообще не нужны ни разу. Эмулировать что-то таким способом тоже не очень то удобно и уж темболее я не хочу увидеть такой код (ваш пример с реализацией тайпхинтинга для скаляров на базе этой штуки) у себя в продакшене.

LastDragon 26 янв 2015 в 05:36

> В вашем примере есть еще одна проблема — make всегда должен возвращать B.

Это не проблема, особенно если вспомнить что type hinting в такой ситуации прекрасно умеет проверять цепочку наследования и выбрасывать E_RECOVERABLE_ERROR.

Fesor 26 янв 2015 в 08:45

я про то что метод find может вернуть null, а в текущем варианте при использовании тайпхинтинга — не может. Потому пример предложенный на java в php пока реализовать не удастся.

symbix 26 янв 2015 в 09:20

Аббревиатура LSP вам о чем-нибудь говорит?

sectus 26 янв 2015 в 09:51

Постусловия не могут быть ослаблены в подклассе.

Вроде всё пучком. В приведённых примерах постусловие усиливается.

symbix 26 янв 2015 в 11:27

Если всегда в возвращаемом значении ожидается instanceof A, то все пучком, но тогда и нет смысла в таком переопределении.

sectus 28 янв 2015 в 08:10

Аббревиатура LSP вам о чем-нибудь говорит?

Тогда я не понял что Вы имели в виду, можете пояснить?

sferrka 26 янв 2015 в 01:51

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

ИМХО, проблема скалярных типов не в возвращаемом значении, а в отсутствии методов

__toBool
__toInt
__toFloat

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

$a = new Bool;
if ($a)

Приговор «код, который я написал 10 лет назад, по-прежнему должен запускаться сегодня и должна быть возможность выполнить его через 10 лет»

Вроде за 10 лет была куча изменений, которые ломали обратную совместимость — хотя бы, выводили NOTICE или WARNING, что уже половину сайтов делало не работоспособными.

Fesor 26 янв 2015 в 02:18

github.com/php/php-src/pull/998 — я расчитываю на то что в 7.0 это дело все же войдет.

sferrka 26 янв 2015 в 11:32

Может вы знаете, есть какой-нибудь простой способ собрать php с этим делом?

Fesor 26 янв 2015 в 15:55

Да, перейти на Hack. Ну а так — собрать так же как и сам php. configure && make.

Casus 26 янв 2015 в 13:53

Вариант Nikic, с преобразованием примитивов в полноценные объекты, мне больше нравится. Такм образом можно будет убрать бардак с именнами и аргументами стандартных функций в PHP, и как бонус заработает TypeHinting для «примитивов».

Fesor 26 янв 2015 в 15:55

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

Имхо превращать все в объекты это не сильно практично. Ну и проблемы тайпхинтинга для содержимого массивов это никак не решает. Как по мне так уж лучше на Hack перейти за всем этим добром.

Casus 28 янв 2015 в 17:19

— int, string и т.д. как примитивы явно останутся, ибо совместимость.
— phpng уменьшит размеры структур.
— другой альтернативы исправить php api, я не вижу.
— type hinting заработает бонусом.

С массивами сложнее… в php вообще с колекциями плохо, даже в spl.

А к Hack я уже давно присматриваюсь. Останавливает только отсутствие поддержки нативных php расширений, а переписывать не хочется.

Fesor 28 янв 2015 в 17:55

Можете первый пункт раскрыть? Если я правильно понимаю, в этом случае нужно править синтаксис языка, причем не слабо.

В интерналс сейчас идет обсуждение единого API для расширений под HHVM и PHP. Правда думаю долго еще ждать и не факт что что-то такое вообще будет. Я стараюсь реже использовать какие-то кастомные расширения как раз таки для того что бы код был максимально переносим.

SerafimArts 29 янв 2015 в 00:15

другой альтернативы исправить php api, я не вижу.

Предлагаю всё же попробовать заглянуть на светлую сторону jphp ;) Ну например: github.com/jphp-compiler/jphp/blob/master/jphp-runtime/src/main/resources/JPHP-INF/sdk/php/lib/str.php

LastDragon 26 янв 2015 в 05:19

> не будет возможности вернуть скалярные значения, такие как string, int, bool и др.

Учитывая что они свободно конвертируются друг в друга это не особо печально.

> нельзя будет определить возврат нескольких типов.

Есть языки где это возможно?

> Некоторые люди также жаловались на объявления типа после закрывающей скобки списка аргументов, а не перед именем функции, но для меня это придирки. Популярные языки, такие как современный C++, используют “пост”-синтаксис, при этом сохраняется возможность поиска «function foo» без какой-либо необходимости прибегать к regex-модификациям.

Несколько странно видеть сравнение с с++, разве java/c# не ближе? «Поиск» вообще не актуален, IDE давным-давно решили данную проблему. ИМХО, префиксная запись гораздо читабельнее, особенно при большом количестве аргументов.

> Понятно, сломанная совместимость всегда огорчит некоторых людей

Тони похоже просто говнокодер, конструкторы совпадающие с именем класса во всех книгах/статьях не рекомендованы к использованию еще со времен перехода с 4.0 на 5.0, поэтому в нормальном коде эта проблема не может существовать в принципе. Буду рад если выпилят (большая часть остального тоже давным давным устарела).

> Как вы относитесь PHP7 в целом?

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

d5v 26 янв 2015 в 07:28

> нельзя будет определить возврат нескольких типов.

Есть языки где это возможно?

Swift?

func minMax(array: [Int]) -> (min: Int, max: Int) {
    var currentMin = array[0]
    var currentMax = array[0]
    for value in array[1..<array.count] {
        if value < currentMin {
            currentMin = value
        } else if value > currentMax {
            currentMax = value
        }
    }
    return (currentMin, currentMax)
}

LastDragon 26 янв 2015 в 07:43

А это разве не кортеж? (структура/массив)

MaximChistov 26 янв 2015 в 07:46

возврат нескольких переменнных это другое.

gro 26 янв 2015 в 08:20

>Учитывая что они свободно конвертируются друг в друга это не особо печально.

Какая вообще связь?

>Есть языки где это возможно?

В PHP есть возможность возвращать значение разных типов, но указать этого нельзя.

LastDragon 26 янв 2015 в 08:39

Оно не особо нужно из-за конвертации: сейчас по сути все равно что возвращает метод 0, false, null или еще что-то приводящееся к false. Если же вам это критично всегда можно явно привести тип. Да и опять же — скалярного type hinting все равно нету, добавлять так все вместе.

gro 26 янв 2015 в 08:46

Ну, если мы идём по пути увеличения строгости, то уже должно быть важно, 0 или NULL.

Fesor 26 янв 2015 в 08:48

в текущей RFC тайпхинтинга для скаляров всеравно нету ничего для проверки содержимого массивов… грусть печаль.

impwx 26 янв 2015 в 20:11

Есть языки где это возможно?

Typescript же!

DonkeyHot 26 янв 2015 в 05:53

Долго не мог понять это место «возвращаемыми могут быть лишь те типы, которые есть на данный момент» и почему это типов int и bool на данный момент нету.
ИМХО надо пояснение, что речь идет о типах, которые можно было использовать в type hinting аргументов ф-ий.

Irker 26 янв 2015 в 07:26

Еще есть интересный rfc про дефолтные конструкторы для объектов. Вещь далеко не критичная, но удобная например при написании юнит тестов. Увы проголосовали 50/50, но так как это изменение на уровне языка, то требуется 2/3+1 голос для принятия.

Fesor 26 янв 2015 в 08:50

А можете пояснить, в чем удобство для написания юнит тестов?

Irker 26 янв 2015 в 09:37

В моей практике постоянно нужно следить существует или нет конструктор создаваемого объекта, чтобы его замокать. Но не удивлюсь, что в phpunit это уже давно решили какой-нибудь проверкой на существование конструктора (буду честен — не проверял).
Также есть удобство в написании конструкторов дочерних классов (это был кстати основной аргумент автора rfc), когда можно было бы всегда смело писать parent::__construct() независимо от того, есть он или нет.

smarthomeblog 26 янв 2015 в 08:28

Целиком и полностью за избавление от пережитков PHP4 — лучше переделать свое приложение, чем опять тащить кучу ненужного барахла в новую версию. Насчет типизации возвращаемых функцией значений. ИМХО зачем делать еще одну Java или Ruby? Или с этой фичей говнокод сразу станет конфеткой? Выбросить балласт — очень правильное решение. Наворачивать избыточный функционал — ИМХО нет.

Fesor 26 янв 2015 в 08:56

Почему вы считаете что этот функционал избыточен? В любом случае право использовать тайпхинтинг или нет — ваше право.