PHP 8: код «До» и «После» (сравнение с PHP 7.4)

Автор оригинала: Brent
  • Перевод


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

Подписчики событий с атрибутами


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

В последнее время я работал над системами, где такой настройки было очень много. Возьмём пример:

class CartsProjector implements Projector
{
    use ProjectsEvents;

    protected array $handlesEvents = [
        CartStartedEvent::class => 'onCartStarted',
        CartItemAddedEvent::class => 'onCartItemAdded',
        CartItemRemovedEvent::class => 'onCartItemRemoved',
        CartExpiredEvent::class => 'onCartExpired',
        CartCheckedOutEvent::class => 'onCartCheckedOut',
        CouponAddedToCartItemEvent::class => 'onCouponAddedToCartItem',
    ];

    public function onCartStarted(CartStartedEvent $event): void
    { /* … */ }

    public function onCartItemAdded(CartItemAddedEvent $event): void
    { /* … */ }

    public function onCartItemRemoved(CartItemRemovedEvent $event): void
    { /* … */ }

    public function onCartCheckedOut(CartCheckedOutEvent $event): void
    { /* … */ }

    public function onCartExpired(CartExpiredEvent $event): void
    { /* … */ }

    public function onCouponAddedToCartItem(CouponAddedToCartItemEvent $event): void
    { /* … */ }
}

PHP 7

У атрибутов в PHP 8 есть два преимущества:

  • Код для настройки слушателей событий и обработчиков собран в одном месте, и мне не нужно прокручивать файл до начала, чтобы узнать, правильно ли настроен слушатель.
  • Мне больше не нужно беспокоиться о написании и управлении именами методов в виде строк (когда IDE не может их автозаполнить, нет статического анализа опечаток и не работает переименование методов).

class CartsProjector implements Projector
{
    use ProjectsEvents;

    @@SubscribesTo(CartStartedEvent::class)
    public function onCartStarted(CartStartedEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartItemAddedEvent::class)
    public function onCartItemAdded(CartItemAddedEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartItemRemovedEvent::class)
    public function onCartItemRemoved(CartItemRemovedEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartCheckedOutEvent::class)
    public function onCartCheckedOut(CartCheckedOutEvent $event): void
    { /* … */ }

    @@SubscribesTo(CartExpiredEvent::class)
    public function onCartExpired(CartExpiredEvent $event): void
    { /* … */ }

    @@SubscribesTo(CouponAddedToCartItemEvent::class)
    public function onCouponAddedToCartItem(CouponAddedToCartItemEvent $event): void
    { /* … */ }
}

PHP 8

Static вместо doc-блоков


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

Если в PHP 7.4 мне нужно было писать:

/**
 * @return static
 */
public static function new()
{
    return new static();
}

PHP 7.4

То теперь достаточно:

public static function new(): static
{
    return new static();
}

PHP 8

DTO, передача свойств и именованных аргументов


Я довольно много писал об использовании системы типов PHP и паттерна DTO (data transfer objects). Естественно, я часто использую DTO в своём собственном коде, поэтому можете представить, насколько я счастлив, что теперь имею возможность переписать это:

class CustomerData extends DataTransferObject
{
    public string $name;

    public string $email;

    public int $age;
    
    public static function fromRequest(
        CustomerRequest $request
    ): self {
        return new self([
            'name' => $request->get('name'),
            'email' => $request->get('email'),
            'age' => $request->get('age'),
        ]);
    }
}

$data = CustomerData::fromRequest($customerRequest);

PHP 7.4

Вот, так-то лучше:

class CustomerData
{
    public function __construct(
        public string $name,
        public string $email,
        public int $age,
    ) {}
}

$data = new CustomerData(...$customerRequest->validated());

PHP 8

Обратите внимание на использование передачи свойств конструктора как именованных параметров. Да, их можно передавать с помощью именованных массивов и оператора Spread.

Перечисления и match


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

/**
 * @method static self PENDING()
 * @method static self PAID()
 */
class InvoiceState extends Enum
{
    private const PENDING = 'pending';
    private const PAID = 'paid';

    public function getColour(): string
    {
        return [
            self::PENDING => 'orange',
            self::PAID => 'green',
        ][$this->value] ?? 'gray';   
    }
}

PHP 7.4

Я бы сказал, что для более сложных условий вам лучше использовать паттерн Состояние, но есть случаи, когда достаточно перечисления. Этот странный синтаксис массива уже является сокращением для более громоздкого условного выражения:

/**
 * @method static self PENDING()
 * @method static self PAID()
 */
class InvoiceState extends Enum
{
    private const PENDING = 'pending';
    private const PAID = 'paid';

    public function getColour(): string
    {
        if ($this->value === self::PENDING) {
            return 'orange';
        }
    
        if ($this->value === self::PAID) {
            return 'green'
        }

        return 'gray';
    }
}

PHP 7.4 — альтернативный вариант

Но в PHP 8 вместо этого мы можем использовать match.

/**
 * @method static self PENDING()
 * @method static self PAID()
 */
class InvoiceState extends Enum
{
    private const PENDING = 'pending';
    private const PAID = 'paid';

    public function getColour(): string
    {
        return match ($this->value) {
            self::PENDING => 'orange',
            self::PAID => 'green',
            default => 'gray',
        };
}

PHP 8

Объединения вместо doc-блоков


Это работает аналогично тому, что было описано ранее для возвращаемого типа static.

/**
 * @param string|int $input
 *
 * @return string 
 */
public function sanitize($input): string;

PHP 7.4

public function sanitize(string|int $input): string;

PHP 8

Генерация исключений


Раньше вы не могли использовать throw в выражении, а это означало, что вам приходилось писать, например, вот такие проверки:

public function (array $input): void
{
    if (! isset($input['bar'])) {
        throw BarIsMissing::new();
    }
    
    $bar = $input['bar'];

    // …
}

PHP 7.4

В PHP 8 throw стало выражением, что означает, что вы можете использовать его вот так:

public function (array $input): void
{
    $bar = $input['bar'] ?? throw BarIsMissing::new();

    // …
}

PHP 8

Оператор nullsafe


Если вы знакомы с оператором null coalescing (коалесцирующий), вам известны его недостатки: он не работает с вызовами методов. Поэтому мне часто были нужны промежуточные проверки или подходящие для этой цели функции фреймворков:

$startDate = $booking->getStartDate();
$dateAsString = $startDate ? $startDate->asDateTimeString() : null;

PHP 7.4

С появлением оператора nullsafe я могу решить эту задачу гораздо проще.

$dateAsString = $booking->getStartDate()?->asDateTimeString();

PHP 8

А какие нововведения в PHP 8 считаете важными вы?



На правах рекламы


Серверы для разработки и размещения ваших проектов. Каждый сервер подключён к защищённому от DDoS-атак каналу в 500 Мегабит, есть возможность использовать высокоскоростную локальную сеть. Мы предлагаем большой выбор тарифных планов, смена тарифа в один клик. Очень удобная панель управления серверами и возможность использовать API. Поспешите проверить!

VDSina.ru
Серверы в Москве и Амстердаме

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

    0
    Кто-нибудь вообще понял что тут автор написал? :)
      +4
      Радость от синтаксического сахара у автора.
        +1
        фух, как от сердца то отлегло, думал я один такой ))
        +2

        У меня на 7.4 под Windows перестал работать preg replace callback, если в качестве аргумента указан eval строковое обращение к protected методу этого же класса через self. Пришлось заталкивать всю функцию в аргументы prc.

          0
          Это как? Можно код?
            –1
            Вот листинг:

            1). В 7.2 под UNIX работало прекрасно

            	protected static function hexEntToLetter( string $ord ): string {
            
            		$ord = $ord[1];
            
            		if( preg_match('/^x([0-9a-f]+)$/i', $ord, $match) ) {
            
            			$ord = hexdec($match[1]);
            
            		} 
            		else {
            
            			$ord = intval($ord);
            
            		}
            
            		$no_bytes = 0;
            
            		$byte = [];
            
            		if ($ord < 128) {
            
            			return chr($ord);
            
            		}
            		else if ($ord < 2048) {
            
            			$no_bytes = 2;
            
            		}
            		else if ($ord < 65536) {
            
            			$no_bytes = 3;
            
            		}
            		else if ($ord < 1114112) {
            
            			$no_bytes = 4;
            
            		}
            		else {
            
            			return ''; 
            
            		}
            
            		switch( $no_bytes ) {
            
            			case 2: 
            
            				$prefix = [ 31, 192 ];
            
            				break;
            
            			case 3: 
            
            				$prefix = [ 15, 224 ];
            
            				break;
            
            			case 4: 
            
            				$prefix = [ 7, 240 ];
            
            		}
            
            		for( $i = 0; $i < $no_bytes; $i++ ) {
            
            			$byte[ $no_bytes - $i - 1 ] = (($ord & (63 * pow(2, 6 * $i))) / pow(2, 6 * $i)) & 63 | 128;
            
            		}
            
            		$byte[0] = ( $byte[0] & $prefix[0] ) | $prefix[1];
            
            		$ret = '';
            
            		for ($i = 0; $i < $no_bytes; $i++) {
            
            			$ret .= chr($byte[$i]);
            
            		}
            
            		return $ret;
            
            	}
            
            	protected static function hexToSymbols( string $s ): string {
            
            		return preg_replace_callback('/([0-9a-fx]+);?/mi', 'self::hexEntToLetter', preg_replace('/\\\\u?{?([a-f0-9]{4,}?)}?/mi', '$1;', urldecode($s)));
            
            	}
            


            Пришлось сделать не красиво:

            	protected static function hexToSymbols( string $s ): string {
            
            		return preg_replace_callback(
            
            			'/([0-9a-fx]+);?/mi', function( $ord ) {
            
            				$ord = $ord[1];
            
            				if( preg_match('/^x([0-9a-f]+)$/i', $ord, $match) ) {
            
            					$ord = hexdec($match[1]);
            
            				} 
            				else {
            
            					$ord = intval($ord);
            
            				}
            
            				$no_bytes = 0;
            
            				$byte = [];
            
            				if ($ord < 128) {
            
            					return chr($ord);
            
            				}
            				else if ($ord < 2048) {
            
            					$no_bytes = 2;
            
            				}
            				else if ($ord < 65536) {
            
            					$no_bytes = 3;
            
            				}
            				else if ($ord < 1114112) {
            
            					$no_bytes = 4;
            
            				}
            				else {
            
            					return ''; 
            
            				}
            
            				switch( $no_bytes ) {
            
            					case 2: 
            
            						$prefix = [ 31, 192 ];
            
            						break;
            
            					case 3: 
            
            						$prefix = [ 15, 224 ];
            
            						break;
            
            					case 4: 
            
            						$prefix = [ 7, 240 ];
            
            				}
            
            				for( $i = 0; $i < $no_bytes; $i++ ) {
            
            					$byte[ $no_bytes - $i - 1 ] = (($ord & (63 * pow(2, 6 * $i))) / pow(2, 6 * $i)) & 63 | 128;
            
            				}
            
            				$byte[0] = ( $byte[0] & $prefix[0] ) | $prefix[1];
            
            				$ret = '';
            
            				for ($i = 0; $i < $no_bytes; $i++) {
            
            					$ret .= chr($byte[$i]);
            
            				}
            
            				return $ret;
            
            			}, preg_replace(
            	
            				'/\\\\u?{?([a-f0-9]{4,}?)}?/mi', 
            	
            				'$1;', 
            
            				urldecode($s)
            	
            			)
            		
            		);
            
            	}
            


            Еще у меня модели сломались. Раньше код не выбрасывал ошибку и исправно работал:

            		$user = iterator_to_array(
            
            			$model::get( 'users', [
            
            				'criterion' => 'email::'. $email,
            
            				'bound'		=> [
            
            					1
            
            				],
            
            				'course'	=> 'backward',
            				'sort' 		=> 'id'
            
            			]),
            
            		)['model::users'];
            
            


            Сейчас, видимо, в аргументах нельзя запятую в конце оставлять.
              +3
              У вас входной аргумент у первого метода должен быть array, а не string, кроме того, в регулярках какой-то адок, там явно что-то неправильно работает.

              Какую вы задачу вообще решаете этим кодом?
                0
                похоже на костыль для конвертации экранированного юникода.
                  0
                  Похоже, да, но хотелось бы убедиться, там какие-то слеши в регулярках ещё.

                  Full-R, верно ли, что весь этот код можно заменить на
                  $ php -r 'var_dump(html_entity_decode("&#10731;&#x02A13;", ENT_XML1, "UTF-8"));'
                  string(7) "⧫⨓"
                    0

                    Попробую вечером проверить будет ли работать также.

                      0
                      Верно. Код вроде работает также. Теперь использую html_entity_decode().

                      Спасибо!
                    0

                    Именно string, а не array. Этот код — это часть модуля для чистки SVG и HTML от XSS и по белому списку атрибутов. Он разворачивает entity's и роется в base64 до второй глубины, чтобы восстановить графику, если в ней найден запрещённый правилами JavaScript.


                    Используется везде, где разрешен HTML. Например, в письмах.
                    https://github.com/Full-R/RevolveR-CMF/blob/master/Kernel/Modules/Markup.php


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

                      +1
                      Он имеет ввиду вот этот момент:
                      protected static function hexEntToLetter( string $ord ): string {
                          $ord = $ord[1];
                      


                      в колбек для preg_replace_callback всегда передается массив матчей, даже если матч будет только один.

                      Вы сами же потом берете у массива $ord второй элемент, но почему-то в сигнатуре функции обозначили $ord как string.
                        0

                        Код уже исправлен на


                        protected static function hexToSymbols( string $s ): string {
                        
                            return preg_replace_callback(
                        
                                '/([0-9a-fx]+);?/mi', function( $ord ) {
                        
                                    $ord = $ord[1];

                        Тип явно не указываю. Спасибо.

                          0
                          Ваш первый вариант у меня работает (PHP 7.4.8, MacOS), если исправить тип параметра. Посмотрите чуть выше, похоже весь этот код одной строкой надо заменить.
                        0
                        Что конкретно вы делаете в этом методе, можете сказать?
                          0

                          Маскированные хексом символы преобразую в текстовый вид.

                      +2
                      Пришлось сделать не красиво

                      Не хочу вас расстраивать..., но до этого тоже было так себе.


                      если в качестве аргумента указан eval строковое обращение к protected методу этого же класса через self.
                      Потому что не нужно так делать.

                      <?php
                      
                      class A {
                          public static function b() {
                              echo "Hello World!" . PHP_EOL;
                          }
                          
                          public static function callSelf()
                          {
                              [self::class, 'b']();
                              [static::class, 'b']();
                          }
                      }
                      
                      A::callSelf();
                      [A::class, 'b']();
                  +6
                  Это просто гениально!
                  public function sanitize(string|int $input): string;
                  Сначала мы говорим, что хотим строгую типизацию, но потом сами же в нее не влезаем)))
                    0
                    А что тут нестрогого?
                      0
                      Например то, что метод может принимать один и тот же параметр разных типов. Отсюда в теле метода лишние проверки, преобразования и т.д.
                      В C# для таких целей есть перегрузка. В PHP к такому ещё не пришли.
                        +2
                        Например то, что метод может принимать один и тот же параметр разных типов.

                        Классический пример любого языка со строгой типизацией, где есть алгебраические типы данных. Отвечая вашими словами: В C# к такому ещё не пришли (https://github.com/dotnet/csharplang/issues/399).


                        С другой стороны, а как вообще можно реализовать перегрузку при наличии такой, более мощной системы типов? Я вот не припомню ни одного языка, где есть подобное: Swift? TS? А про функциональный Idris даже говорить не стоит. Может я какой-то пропустил, где подобное есть?

                          0

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

                            0
                            Вот это: string|int не алгебраический тип данных, а кривой костыль, использование которого говорит о том, что метод, использующий такой тип, спроектирован некорректно.

                            Во-первых, примитивный тип не может быть алгебраическим.

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

                              Это уже не примитивный, как не крути. Список примитивных типов фиксирован, а тут комплексный тип.


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

                              Кому должен? Откуда такие требования?

                                0
                                Это уже не примитивный, как не крути. Список примитивных типов фиксирован, а тут комплексный тип.

                                Здесь int примитивный тип. Тип «или int, или строка» не алгебраический, из-за использования инта.

                                Кому должен? Откуда такие требования?

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

                                Ключевая фраза здесь: "используется сопоставление с образцом" (другими словами это паттерн матчинг). Если вам заранее неизвестны все классы, то и написать всеобъемлющий паттерн матчинг вы не сможете.

                                  0
                                  Тип «или int, или строка» не алгебраический, из-за использования инта.

                                  Комплексные, составные типы данных для меня означают, прежде всего, комбинации примитивных типов. Какие конкретно комбинации (объединение, структура, какая-нибудь коллекция и т. д.) — детали.


                                  Вы можете посмотреть как алгебраические типы данных реализованы в других языках или почитать статью на википедии, вот цитата:

                                  Как реализованы в других языках — дело десятое. Главное — определения.

                                    0
                                    составные типы данных для меня означают
                                    Ясно, понятно.
                                    Главное — определения.
                                    В моем комментарии выше есть определение алгебраического типа данных и структура «int|string» в него не укладывается.
                                      0

                                      Не вижу определения. Описание того, что делает конструктор, вы называете определением типа данных?

                                    0

                                    Ну вот тут имеем, что все классы известны (их два: int и string), и сопоставление делается без проблем — как в текстовом виде (int даёт число из цифр, с возможным минусом, а string — строку, обычно в двойных кавычках), так и внутри программы (int и string отличаются).
                                    Что вам не нравится?
                                    Или в PHP, аналогично Perl и JS, нет жёстких границ между числом и строкой? Ну тогда частично согласен, но это проблема одного конкретного языка.

                                      0

                                      Границы более чёткие чем в них, но не сильно и есть нюансы, зависящие от режима работы строгий или нет. В принципе с int|string могут быть неоднозначности, если передать числовую строку в нестрогом режиме: если просто int, то она преобразуется, но проверил в int проходят только числа, любые строки, включая числовые, после тайпхитинга — строки — попыток преобразования строк в число нет, как было бы с голым int в нестрогом режиме

                              0
                              Зато в теле вызывающего таких проверок нет.
                              Вот реально, научи дурака солиду молиться:)
                                0
                                Отсюда никак не следует, что типизация тут нестрогая.
                                  0
                                  Отсюда никак не следует, что типизация тут нестрогая.

                                  Именно это и следует. Если нет, что что тогда такое для вас строгая типизация?
                                    0

                                    Тут нет возможности выполнить с аргументами, отличными от string или int, которые явно указаны. Строгая типизация не допускает исполнения с типами, противоречащими декларации и системе типов. Тут вы не сможете передать объект или булево, NPE внутри функции исключён гарантиями языка.

                                      0
                                      Тут нет возможности выполнить с аргументами, отличными от string или int


                                      То что в качестве аргумента можно передать или int, или string это уже не строгая типизация. При строгой типизации метод или принимает только int, или принимает только string.
                                        0

                                        Это ваша личная трактовка, да?

                                          +2
                                          Это ваша личная трактовка, да?

                                          Нет. Давайте начнем отсюда:
                                          По одной из классификаций, языки программирования неформально делятся на сильно и слабо типизированные.

                                          В русскоязычной литературе часто используется термин «строгая типизация»; общепринятый вариант «сильная типизация» используется лишь при противопоставлении «слабой типизации».

                                          Теперь посмотрим сюда:
                                          Стати́ческая типиза́ция — приём, широко используемый в языках программирования, при котором переменная, параметр подпрограммы, возвращаемое значение функции связывается с типом в момент объявления и тип не может быть изменён позже (переменная или параметр будут принимать, а функция — возвращать значения только этого типа)

                                          Определение «int|string» это не тип, это указание на то, что в этом месте будет или тип int, или тип string, что противоречит определению из цитаты выше.
                                            0
                                            Это union type, объединённый тип.
                                              0
                                              Почитал про юнион типы в PHP 8, в этом посте в качестве примера приводится тип «int|float». Такой тип в сравнении с «int|string» имеет хоть какой-то смысл.

                                              С точки зрения разработчиков PHP это действительно отдельный тип, но с точки зрения здравого смысла это выглядит очень странно. Эту идею можно развить до примерно следующей (псевдокод):
                                              interface Animal
                                              class Cat implements Animal
                                              class Dog implements Animal
                                              
                                              interface Vehicle
                                              class Car implements Vehicle
                                              class Moto implements Vehicle
                                              
                                              function process(Animal|Vehicle $item)
                                              


                                              Очевидно, что метод с такой сигнатурой спроектирован некорректно, не может один метод что-то делать и с животными, и с транспортом. Точно также и «int|string» говорит о некорректном дизайне метода, даже если с точки зрения разработчиков языка это валидная конструкция.
                                                0
                                                Очевидно, что метод с такой сигнатурой спроектирован некорректно, не может один метод что-то делать и с животными, и с транспортом.

                                                Может. Например регистрировать в реестре с бизнесовой точки зрения или сохранять состояние или сериализировать с технической

                                                  +1
                                                  Нет. В таком случае метод на вход должен принимать тип Registerable или Serializable (названия из головы), а соответствующие классы их должны имплементить.
                                                    0

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

                                                      0
                                                      В долгосрочной перспективе с таким подходом ничего хорошего не получится. В случае если у нас есть десятки типов, которые надо как-то регистрировать или сериализовать, то метод, принимающий на вход много разных типов получится похожим на что-то вроде:
                                                      function register($input) {
                                                        if ($input instanceof Type1) { /* do smth with Type1 */}
                                                        elseif ($input instanceof Type2) { /* do smth with Type2 */}
                                                        // ...
                                                        elseif ($input instanceof Type999) { /* do smth with Type999 */}
                                                      }
                                                      


                                                      В случае с интерфейсом Registerable код будет предельно простым:
                                                      function register(Registerable $input) {
                                                        $input.register();
                                                      }
                                                      


                                                      В случае если мы не контролируем тип, который надо зарегистрировать, то просто делаем для него обертку:
                                                      class RegisterableInt implements Registerable {
                                                        function register(int $input) {
                                                          // do smth with int
                                                        }
                                                      }
                                                      


                                                  0
                                                  с точки зрения здравого смысла это выглядит очень странно
                                                  Считаете ли вы, что union types тоже с точки зрения здравого смысла выглядят странно? Между «int|float» и union type разница только лишь в том, что «int|float» не имеет названия (уже сейчас планируется к реализации в будущем, смотреть RFC).

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

                                                  не может один метод что-то делать и с животными, и с транспортом
                                                  Животное, как и транспорт, можно загонять в помещения, которые подходят исключительно под животных и транспорт из-за отсутствия «лицензии» на хранение всего другого.

                                                  Если вы спросите кто будет отвечать за «загон», то ни животное, ни транспорт, ни помещение, а отдельная «сторона» — человек.

                                                  Также вас может заинтересовать каким образом будет осуществляться «поддержка хранения» животных или транспорта. В таком случае отвечу, что это так же лежит на отдельной сущности. Помещение вполне может быть не обязано следить за «состоянием» животного или транспорта.

                                                  Я считаю, что существуют случаи, когда в каком-то из мест системы интерфейсы могут быть не нужны.
                                                    0
                                                    но с точки зрения здравого смысла это выглядит очень странно.

                                                    Есть области, где подобный здравый смысл вынужден отступить перед реальностью. Вот, например, вы тянете данные из электронной таблицы (Excel, Google Sheets...), а там по умолчанию автоопределение типа по содержимому (может, и нельзя фиксировать тип — я искал и не нашёл). И если вы читаете из подобного, должны быть готовы, что поступит string, которое на самом деле должно содержать целое, плавучее, дату или ещё что-то, или дату вместо денег, и прочая и прочая.

                                                  0

                                                  Это анонимный объединённый тип. Тип-сумма, логическая дизъюнкция, тип, множество значений которого является объединением множеств всех значений int и всех значений string. Ничего другого язык не пропустит и/или не вернёт.

                                                    0
                                                    Ничего другого язык не пропустит и/или не вернёт.
                                                    Это понятно. Но на стороне клиентского кода все равно будет неочевидно, что конкретно будет возвращено методом: число или строка, отсюда мой вывод о том, что это не может считаться строгой типизацией.

                                                    Кроме того смешивание чисел и строк это явный пример плохого дизайна, как в моем примере выше. И если в случае «Animal|Vehicle» ошибка дизайна очевидна, то чем в таком случае отличается пример с «int|string».
                                                      0

                                                      Очевидность — это не про строгую типизацию :) Для анализатора и/или рантайма будет очевидно (в некоторых случаях, если о PHP говорить) что пытаются обращаться с результатом, не сделав проверки на тип и он будет требовать её сделать или явно привести.

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

                                        В том плане, что предположим, перегрузка бы была. Тогда:

                                        class A {
                                        	public function foo(int $a, int $b = 0): void {
                                        		echo "1";
                                        	}
                                        
                                        	public function foo(int $a): void {
                                        		echo "2";
                                        	}
                                        }
                                        
                                        $x = new A();
                                        $x->foo(123); // что выведется?
                                        
                                          0
                                          по-нормальному и не сделаешь перегрузку из-за поддержки значений по-умолчанию для параметров
                                          Как минимум в Delphi нашли способ сделать. Если разработчиком будут написаны «неоднозначные» декларации методов, то процесс компиляции будет остановлен с ошибкой.

                                          что выведется?
                                          PHP Fatal Error?
                                            0
                                            Мне следовало выразиться более точно: в скриптовых языках обычно либо то, либо другое.
                                      0
                                      пока не будет дженериков хрен нам а не строгая типизация 8(
                                        –3
                                        А, простите, зачем?
                                        Вот реально, тяжёлый матан на пыхе не пишут. А дженерики, как и шаблоны плюсов, тащат только на матане, когда можно выбрать тип данных — байт или complex<double>, причём только в случае, если оба поддерживаются процессором/видеокартой.
                                        В тех же плюсах вы технически можете засунуть в условную сортировку пузырьком тип Список или Хэш. Но вот честно — лучше бы не могли. Потому что она и так плоха, но на всём кроме настоящих массивов в стиле С совсем днище.
                                          +5

                                          Типизированных коллекции — это матан? Промисы?

                                            +1
                                            Затем что заколебали костыли с коллекциями. Еще больше заколебал меня синтаксис аля доктрины с 95% кода в комментариях.
                                            +2

                                            есть psalm.
                                            Дженерики, равно как и тайпчек в рантайме не нужны

                                              +2
                                              Дженерики <...> не нужны

                                              Мощно.

                                                +2

                                                Особенно со ссылкой на psalm, где они есть.

                                                  0

                                                  Советую открыть для себя psalm. Ну и до кучи попробовать разобраться: для чего вам в рантайме (!) нужны дженерики.

                                              0
                                              Сначала мы не хотим возится с этими типами, потом мы вдруг понимаем, что нам нужна типизация, а уже потом мы в нее не влезаем.
                                              То, что происходит с php меня очень забавляет.
                                              Сам я устал от php. Писал на нем лет восемь и стоило один раз попробовать c++ — и боже мой! Это так прекрасно!
                                              А сейчас php пытается в строгость. Но какой от нее толк, если все эти проверки происходят в момент выполнения кода? Да, конечно, у вас всех умная IDE, которая всё подсвечивает (а чаще не всё), и прикрученный статический анализатор. Но это костыли.
                                                +2
                                                Сам я устал от php. Писал на нем лет восемь и стоило один раз попробовать c++ — и боже мой! Это так прекрасно!

                                                Рекомендую попробовать Rust, в C++ вы ещё успеете разочароваться.

                                                  0
                                                  Rust уже пробовал. Rust прекрасен. Язык который сам проверяет больше случаев, чем многие статические анализаторы. Это закономерное и логичное развитие ЯП.
                                                  Только вот работы на нем нет. Для меня.
                                              –1
                                              код становится все менее читабельным. Так и до brain***k недалеко :(
                                                –2
                                                иной раз я думаю что пхп стал популярен знаку доллара вначале переменой и тому что там статической типизации шел 20 год, и первый вопрос о приеме на работу студента звучал так. # а знаете ли вы пхп #
                                                  0
                                                  А может кто-нибудь обьяснить как это работает?

                                                          return [
                                                              self::PENDING => 'orange',
                                                              self::PAID => 'green',
                                                          ][$this->value] ?? 'gray';   
                                                  

                                                  
                                                  /**
                                                   * @method static self PENDING()
                                                   * @method static self PAID()
                                                   */
                                                  class InvoiceState extends Enum
                                                  {
                                                      private const PENDING = 'pending';
                                                      private const PAID = 'paid';
                                                  
                                                      public function getColour(): string
                                                      {
                                                          return [
                                                              self::PENDING => 'orange',
                                                              self::PAID => 'green',
                                                          ][$this->value] ?? 'gray';   
                                                      }
                                                  }
                                                  


                                                  Спасибо.
                                                    +1

                                                    Создаётся одноразовая карта соответствий статус => цвет, тут же из неё извлекается элемент по текущему значению статуса и возвращается. Если элемента не существует, то возвращается 'gray' без каких-либо предупреждений или ошибок.

                                                      +2
                                                      Создаем массив
                                                      [self::PENDING => 'orange', self::PAID => 'green',]
                                                      

                                                      Пытаемся взять из него значение по ключу "$this-value"
                                                      [...][$this->value]
                                                      

                                                      Если ключа нет, вернем «gray»
                                                      ?? 'gray'
                                                      


                                                      Альтернативный код:
                                                      $list = [
                                                          self::PENDING => 'orange', 
                                                          self::PAID => 'green',
                                                      ];
                                                      
                                                      if (!array_key_exists($this->value, $list)) {
                                                          return 'gray';
                                                      }
                                                      
                                                      return $list[$this->value];
                                                      
                                                        +2
                                                        Альтернативный код — это просто switch:
                                                        switch ($this->value) {
                                                            case self::PENDING:
                                                                return 'orange';
                                                            case self::PAID:
                                                                return 'green';
                                                            default:
                                                                return 'gray';
                                                        }
                                                        
                                                          0
                                                          Тоже не понял зачем создавать массив под такую задачу (пусть и immutable в случае opcache). Сам смысл `match` — короткая форма `switch`. Куда интересней вот такое использование:
                                                          $message = match ($statusCode) {
                                                              200 => null,
                                                              500 => throw new ServerError(),
                                                              default => 'unknown status code',
                                                          };
                                                            0

                                                            Когда вариантов много, массив как-то проще читается на предмет вход-выход

                                                      0
                                                      Отличные штуки! Заметно, что многие идеи PHP принимает из Java и C# и даже TypeScript.
                                                        0

                                                        Сильно сладко. С таким количеством сахара получается PHPerl какой-то :)

                                                          –3
                                                          Был себе нормальный язык у которого было хотя бы преимущество в читабельности, теперь это похоронили. Ну что ж, похоже теперь на пыхе только вордпресеры останутся писать свою лапшу во вьхах.
                                                            –3
                                                            PHP плавно превращается в самостоятельный фреймворк для формошлёпов… неплохо, да. Нечего полянку нормальных ЯПов занимать. Здесь и так тесно.

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

                                                            Самое читаемое