Открыть список
Как стать автором
Обновить

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

Если вам нужен SOAP, то лучше использовать юзерленд реализации на PHP, а не расширение.

А может кто подсказать актуальные примеры? Быстрый поиск на пакаджисте выдал только phpro/soap-client с довольно жирными аппетитами на зависимости и meng-tian/php-soap-interpreter, по которому не было апдейтов с 2016 года

RFC по акцессорам прям порадовал. Надеюсь, в ближайших релизах будет его реализация
Intersection Types RFC

Так и не придумал, где это можно было бы использовать. Но, даже если и так, не проще ли делать вместо


function RecordsToList(array | Countable & Traversable $input): String {
    // ...
}

Вот так:


interface ListInterface extends \Countable, \Traversable {} 

function RecordsToList(array | ListInterface $input): String {
    // ...
}

Потому что SplObjectStorage, например, подходит под первую сигнатуру RecordsToList, но не подходит под вторую.


Ну и создавать отдельный файл с интерфейсом ради тайпхинта — это уже перебор.

А алгебра в тайпхинтах не перебор?

А для этого и нужны тайпалиасы.


С другой стороны, инлайнинг юнионов — точно такой же перебор, но оно как бы есть уже...

А что насчет методов у примитивных типов? Никита еще в 2014 реализовал такую возможность в виде расширения и написал статью о том что все почти готово, скоро выкатим. И по-моему об этом ни видно, ни слышно по сей день. Может быть я что-то пропустил? Буду признателен если кто-нибудь спросит у Никиты об этом на стриме, так как я, к сожалению, не смогу.
Именованные аргументы не гарантируют совместимость на уровне интерфейсов и значительно увеличивают проблемы BC для OS библиотек.

Есть предложение по атрибуту для задания алиасов #[NamedParameterAlias].

Ну, как я уже говорил (где-то), по-хорошему, надо было делать ровно наоборот: Именованные аргументы должны быть явно определены.


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


Какие перспективы по введению nested attributes?

Это намеренно не разрешено, потому что аргумент атрибута это константное AST

Тут в ответе лукавство, т.к. атрибуты содержат не только константное AST, но и позволяют использовать константные выражения, которые могут вычисляться в рантайме. Таким образом, можно в две строчки туда поместить, например, resource stream, созданный через fopen, который мы приводим к числу и складываем, например, с флоатом.


Мне пришлось в своё время с этим "поразвлекаться", добавляя поддержку атрибутов в PHP 7.


Property Promotion не доделан: Зачем нужны фигурные скобки у конструктора с такими аргументами? Как декларативно их прокинуть в родительский конструктор?

Не помню, чтоб кто-то поднимал этот вопрос. Почему ты не задал его во время обсуждения RFC?

Хм, но вообще, по-моему, это довольно очевидный кейс писать DTO, вида:


class Vec2
{
    public function __construct(
        public float $x = .0,
        public float $y = .0,
    ) {
    }
}

И совершенно ненужные фигурные скобки — прямо бросаются в глаза любому, кто хоть раз пробовал действительно пользоваться этим синтаксисом. С другой стороны, подобный синтаксис тащит за собой несколько других проблем, например с наследованием, что требовало бы отдельного RFC (типа такого: https://github.com/SerafimArts/php-rfcs/blob/shorter-constructor/rfcs/0000-shorter-constructor.md), так что в качестве первой итерации промоушена подобный функционал, возможно, действительно излишний.


Почему добавили match, нарушающий дизайн языка? А если добавляются выражения, то где ""$some = foreach (...) => ..."" или ""$some = if(...) => ...""?"

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

Во-первых, для того, чтобы создать RFC — требуется аналогичный PR с имплементацией. Без кода на C большинство RFC, будем честны, никому не нужны, т.к. это OpenSource. Я прекрасно это понимаю, и будучи совсем безграмотным в ANSI C только и могу, что вбрасывать на вентилятор лишь в комментариях.


Во-вторых, тут претензии не к самой конструкции "нужно или нет", а к дизайну языка как таковому. Это выражение является уникальным в своём роде и выбивается из списка уже существующих как раз тем, что является не статментом. В моём представлении, нужно было не принимать сразу, а сесть и подумать над общим дизайном и тогда бы мы могли прийти, например (sic!), к кейворду expr, т.к. концпеция модификаторов статментов уже регламентирована дизайном языка: private, final, abstract, etc...


// Вместо match
$a = expr switch($x) {
   case 1: return 42;
   case 2: return 23;
}

// Или
$a = expr switch {
   case is_array($value): return 42;
   case is_int($value): return 23;
}

// Новая инструкция
$generator = expr foreach($iter as $value) {
    yield $value;
}

// Новая инструкция
$result = expr if ($a === 42) {
    return 42;
}

// В том числе и с пустыми блочными конструкциями.
$result = expr {
    yield 1;
    yield 2;
}

Где смысл был бы в том, что expr переключал бы режим блочных конструкций в перехват return.


В этом случае неявный return вписывался бы в уже существующие концепции хеш-мап (с некоторой натяжкой) и анонимных функций:


// Вместо match
$a = expr switch($x) {
   case 1 => 42;
   case 2 => 23;
}

// ...
$result = expr if ($a === 42) => 42;

// ...
$iterator = expr foreach ($iter as $value) => $value ? $value + 23 : continue;

Stringable нужен, чтоб можно было использовать объект с __toString() там, где стоит тайпхинт string. C Countable и Serializable такой проблемы нет.

Мне кажется, что это надуманная проблема, которая была решена костылём. С точки зрения дизайна языка, по-моему, это должно было быть решено через отдельное выражение, например implict:


implicit interface Stringable
{
    public function __toString(): string;
}

Получая в итоге возможность объявления интерфейсов, позволяющих неявно имплементироваться на этапе instanceof. Таким образом, мы бы получили обширный простор для неявного полиморфизма (например из Laravel) по аналогии с объектной моделью из Go:


implicit interface Arrayable
{
    public function toArray(): array;
}

// или
implicit interface Renderable
{
    public function render(): string;
}

// где любой класс, вида
class Collection
{
    // ...
    public function toArray(): array { ... }
}

// Всегда возвращал бы
$collection instanceof Arrayable; // true

И это не потребовало бы явно зависеть от этих вендорных интерфейсов при имплементации.




Подытоживая, претензии были к тому что при реализации некоторых фич никто не смотрит на шаг вперёд, а внедряемые (тот же Stringable) выглядят как костыль (потому что никто не мешает написать (method_exists($a, '__toString') вместо $a instanceof Stringable — будет даже короче), призванный решить одну единственную самую популярную проблему, но совершенно игнорируя "WTF эффект", кто с ней столкнётся впервые.

Долго не мог понять, что же меня смущает в этой статье. А потом в теги посмотрел. Неожиданно. :)

Теги: PHP, PHP 8


А что было неожиданным, расскажите, пожалуйста

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

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

Вот есть пачка из 10 стартапов, которые берут для старта условный Laravel, так как это быстро, модно, молодежно. Из 10 стартапов, 8 счастливо загибаются, а оставшиеся 2 набирают жирок и выходят в прибыль и рост.

Постепенно команда дорастает до 10-15 разработчиков, накапливаются человеко-часы на PHP и встречаются определенные проблемы «хайлоада». И так как система уже работает на PHP, уже есть команда из PHP разработчиков, а бизнесу нужен функционал, а не «переписывание на условную Java», начинаются использоваться определенные воркараунды, чтробы обойти ограничения PHP.

Именно так у нас появился Фейсбук, ВК, Авито, Баду, Википедия и прочие проекты размером поменьше, которые работают на ПэХэПэ.

P.s. почему бы сразу не взять «более правильный стек». Ну во-первых, никто не знает, какой стек правильный в долгосрочной перспективе, а какой нет. Во-вторых, если писать стартапы на условной Java, то будет выживать не 2 из 10, а 1 из 50, из-за более дорогих разработчиков и более длительного тайм ту продакшен.

P.s.s. Единственное, что понастоящему смущает на PHP, так это то, что высококласный специалист на PHP получает меньше, чем условный мидло-сениор на Java.
Во-вторых, если писать стартапы на условной Java
Можно писать на Python, Ruby, Typescript. Это последовательные и довольно консистентные языки. Хотя на Ruby пока нельзя, там хуже всего с типами.
P.s.s. Единственное, что понастоящему смущает на PHP, так это то, что высококласный специалист на PHP получает меньше, чем условный мидло-сениор на Java.
Ну так именно поэтому и проще взлететь проекту на РНР. Тут как с переносом производства в развивающиеся страны)
поэтому проще взлететь проекту на РНР

Я с вами не соглашусь.
Языки программирования, это по сути инструменты. Как в строительном магазине.
PHP создавался для быстрого создания веб приложений.
Вы же не будете молотком или кувалдой пилить дерево?
Можно писать на Python, Ruby, Typescript.

На PHP можно сразу начать писать бизнес-логику.
Тогда как у Python и Ruby выше уровень входа.

Typescript больше подходит для фронта.
Typescript больше подходит для фронта.
Почему? Это универсальный ЯП. На нём и куча бэкенда написана тоже, веб-фреймворки там: NestJS, TypeORM. Нормальный ЯП вообще, получше РНР, по-моему, несмотря на торчащие уши ещё более кошмарного ЯП.
Тогда как у Python и Ruby выше уровень входа.
Я не вполне понимаю, что вы имеете под уровнем входа, но Python — это уже в принципе давно ЯП для входа в разработку. Можно начинать так же пилить бизнес-логику весьма быстро, Django не сложнее разобраться, чем Symfony. Если не проще, субъективно РНР практики ушли в бэкенде чуть дальше.
Вы же не будете молотком или кувалдой пилить дерево?
Не буду, но у нас тут вообще-то сравнение разных моделей пилы, то есть скорее пилорамы. На обсуждаемую пилораму можно найти дешевых работников.
Я, впрочем, не думаю, что такая рыночная ситуация серьёзно обоснована — на другие пилорамы довольно легко обучиться.
Единственное, что понастоящему смущает на PHP, так это то, что высококласный специалист на PHP получает меньше, чем условный мидло-сениор на Java

У нас в компании оба стека, оплата одинаковая при равном опыте.


P.s. почему бы сразу не взять «более правильный стек»

А что в PHP неправильного? Да, есть проблемы, но они и в джаве есть. И на мой взгляд в PHP проблем очень мало, это мой любимый язык и связанный с ним стек инструментов и сообщество. Я перешел на него осознанно с других стеков, потому что он мне нравится.
Более того, есть еще Go, который идеально дополняет PHP, они имеют противоположные плохие и хорошие стороны и между ними почти никогда не надо выбирать, потому что и так понятно.

Если изучить глубже любой популярный язык, то выясняется, что в каждом есть свои "дыры" и "заплатки". В Java так особенно.


Процитирую Страуструпа:


“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
Ситуация с дженериками крайне разочаровывающая, практически тупик из-за особенностей РНР. Код получается довольно шизофреничный — везде вроде как тайпхинты, но и кое-где приходится влеплять phpdoc.
В ответе на вопрос «будет ли асинхронный PHP» совсем не упомянули parallel + parallel-pool и его предшественника pthreads

Асинхронщина нужна в PHP core для interoperability.
Чтобы был дефолтный способ с этим работать и инструменты и подходы развивались, помогая друг другу, а не придумывая еще один малофункциональный способ что-то переизобрести.
И вдвойне приятно, если она будет поддерживаться синтаксисом, чем больше — тем лучше.


Про дженерики сказали — крайне необходимая фича. Но вот про что не говорили, так это про application server. Я бы хотел, чтобы php -s был production-уровня (используя код php-fpm, к примеру).

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