Комментарии 21
Если вам нужен SOAP, то лучше использовать юзерленд реализации на PHP, а не расширение.
А может кто подсказать актуальные примеры? Быстрый поиск на пакаджисте выдал только phpro/soap-client с довольно жирными аппетитами на зависимости и meng-tian/php-soap-interpreter, по которому не было апдейтов с 2016 года
Вот это вроде ничего выглядит https://github.com/goetas-webservices/soap-client
Intersection Types RFC
Так и не придумал, где это можно было бы использовать. Но, даже если и так, не проще ли делать вместо
function RecordsToList(array | Countable & Traversable $input): String {
// ...
}Вот так:
interface ListInterface extends \Countable, \Traversable {}
function RecordsToList(array | ListInterface $input): String {
// ...
}
Именованные аргументы не гарантируют совместимость на уровне интерфейсов и значительно увеличивают проблемы 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 эффект", кто с ней столкнётся впервые.
Долго не мог понять, что же меня смущает в этой статье. А потом в теги посмотрел. Неожиданно. :)
Вообщем чет как-то грустно. Такое ощущение что это тупик. Выглядит как попытка залатать дыры и придать товару товарный вид. С ростом популярности дарт, котлин где из коробки асинхронность и компиляция в нативный код, пхп будет все сложнее что-то предложить. Держится видимо только за счёт огромного комьюнити и библиотек на все случаи жизни, ну и хороших фреймворков
Вот есть пачка из 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. Если не проще, субъективно РНР практики ушли в бэкенде чуть дальше.
Вы же не будете молотком или кувалдой пилить дерево?Не буду, но у нас тут вообще-то сравнение разных моделей пилы, то есть скорее пилорамы. На обсуждаемую пилораму можно найти дешевых работников.
Я, впрочем, не думаю, что такая рыночная ситуация серьёзно обоснована — на другие пилорамы довольно легко обучиться.
Если изучить глубже любой популярный язык, то выясняется, что в каждом есть свои "дыры" и "заплатки". В Java так особенно.
Процитирую Страуструпа:
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
PHP 8 и развитие языка в 30 вопросах и ответах