заодно в голове приберешься

можешь рандом юзать

вместо конкретных значений

ну короч, за тебя никто работу деать не будет)

Да ну это понятно) Я бы тоже не стал за кого-то чужую работу делать)

https://tproger.ru/problems/design-an-algorithm-to-find-all-pairs-of-integers-within-an-array-which-sum-to-a-specified-value/

Такое подойдёт для моей задачи?

@Enleur class Site { public $name; public $url; } $site = Site{"name": "Reddit", "url": "https://reddit.com/"};

как тебе такая наркомания?)

MorrisonLevi хочет запилить

в пхп?

Судя по $site, да

Но зачем. Экономить на конструкторах с инициализацией? надо ж както указать будет поля, которые нельзя прокинуть так

MorrisonLevi хочет запилить

неплохо, а дай линк

вот такое было https://wiki.php.net/rfc/automatic_property_initialization, но задеклайнили

таки наркомания пхп это вам не жс

вот такое было https://wiki.php.net/rfc/automatic_property_initialization, но задеклайнили

это еще относительно интересно, но синтаксис не совсем логичный имхо было бы круче что-то вида $x » $this или вроде этого с отдельным оператором на это дело

вот такое было https://wiki.php.net/rfc/automatic_property_initialization, но задеклайнили

не, то другое

неплохо, а дай линк

он это чисто на рэддите пока опубликовал

кривой синтаксис все-равно

ты про мой вариант? или то, что Сергей писал выше?

скорее уж тайпкаст разрешить во все классы

(Site)$array типа

я про {}

да, это криво еще и со строчными ключами - выглядит отстойно

а смысл в чём? чем это лучше обычного/именованного конструктора?

тем, что самому присваивать не надо?)

а смысл в чём? чем это лучше обычного/именованного конструктора?

тем что не нужно его писать

ну такое себе

это аля дата классы в котлине, только php-way

я вот думаю в январе таки заняться исследованием php internals и повоять какого сахара

аля

public function __construct( private EntityManager $em ) {}

ибо дико не хватает после всяких там тайпскриптов или котлинов

я понимаю, что это "аля" но тем не менее не оч

непонятно, что будет происходить

или именно как дата классы эти (как раз смотрю)?

непонятно, что будет происходить

в смысле непонятно? это равносильно следующему: private $em; public function __construct(EntityManager $em) { $this->em = $em; }

чтобы и сразу объявить сущность, и привязать ее...

типа того, сильно упрощает код на самом деле, особенно учитывая что у тебя большая часть классов это содержит

по сути все сервисы

да, упрощает

мне не нравится оно семантически чисто с точки зрения формулировок получается, что метод __construct (который, как ожидается, должен отвечать за конструирование класса) определяет его содержимое

тут как вариант сделать дефолт конструктор который берет все приватные поля в том порядке, в котором описаны

мне не нравится оно семантически чисто с точки зрения формулировок получается, что метод __construct (который, как ожидается, должен отвечать за конструирование класса) определяет его содержимое

потому что формулировка не верна?)

и принимает в себя

с точки зрения клиентского кода сигнатура не меняется

тут как вариант сделать дефолт конструктор который берет все приватные поля в том порядке, в котором описаны

это намного менее явно

порядок объявления полей не должен влиять на порядок аргументов

код для клиента - тоже аргумент насчет неявности - тут уже надо держать баланс

либо я не понял что ты имеешь ввиду

ты понял правильно

я предлагаю вместо private $em и $this->em = $em просто заюзать в аргументе ключевое слово public/private/protected;

получится динамическое объявление на стероидах

private $authData; public function __construct( private SomeService $service, $someToken, $someOtherThing ) { $this->authData = sha1($someToken.someOtherThing); }

не могу сказать, что это плохо

а то что предлагает Морисон Леви, это упростит работу со структурами данных и позволит их делать больше и более структурированными, менее чувствительными к изменениям...

ничего не упростит, кто делал DTO с конструктором - тот и будет делать, а кто не делал - и не будет

ничего не упростит, кто делал DTO с конструктором - тот и будет делать, а кто не делал - и не будет

будет продолжать делать с конструкторами?)

ну да

а ты я смотрю консерватор

я лично рассмотрю хотя бы такой вариант)

нет, я в детсвте магии наелся

где ты тут магию увидел?

или что-то неявное

с такой логикой оператор присвоения и мутация стэйта уже должна становиться для тебя магией

мне в версии Леви не нравятся строчные ключи

ERROR: S client not available

это вроде и логично

ну сахар, ок

сахара я еще больше наелся, 7 лет на перле ;)

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

но блин, удобненько ж

мне в версии Леви не нравятся строчные ключи

да, по синтаксису еще есть вопросы

но лично у меня строки - это либо строки, либо ключи для массивов использовать их еще где-то не люблю как минимум - отсутствие автокомплита нормального

но лично у меня строки - это либо строки, либо ключи для массивов использовать их еще где-то не люблю как минимум - отсутствие автокомплита нормального

то что у тебя литерал строковый автокомлиту не помеха

я дно и пишу дтошки с конструкторами, приватными свойствами и геттерами и мне хорошо :( в задницу магию, публичные свойства и т.д.)

в этом конкретном случае все будет работать

я дно и пишу дтошки с конструкторами, приватными свойствами и геттерами и мне хорошо :( в задницу магию, публичные свойства и т.д.)

тебе хорошо но смайлик ты грустный поставил

https://regex101.com/r/qbwBq9/1/ как взять два id если одно в кавичках , а другое без?

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

лучше уж именованные аргументы ввели, и то больше толку ;)

тебе хорошо но смайлик ты грустный поставил

грустный смайлик в контексте не очень понятного профита от сахара выше)

https://regex101.com/r/qbwBq9/1/ как взять два id если одно в кавичках , а другое без?

xpath и xmldom

лучше уж именованные аргументы ввели, и то больше толку ;)

мне вот чёт в том же питоне не зашло

лучше уж именованные аргументы ввели, и то больше толку ;)

чую питон)

но их зарезали, вроде...

лучше уж именованные аргументы ввели, и то больше толку ;)

нет, я пожалуй уже не очень хочу их видеть

мне они не нравятся в питоне только из-за отсутствия автокомплита

они будут подталкивать людей к тому что бы увеличивать количество аргументов

адекватного, по крайней мере

мне они не нравятся в питоне только из-за отсутствия автокомплита

у меня в pycharm с этим все было ок)

(да, я ide-обезьянка, без автокомплита жить не хочу)

т.е. массив в инициализацию паблик свойств - норм, а массив в конструктор подать - не оч? ;)

у меня в pycharm с этим все было ок)

я тоже пичарм пользую, но что-то мне в этом не нраавилось

т.е. массив в инициализацию паблик свойств - норм, а массив в конструктор подать - не оч? ;)

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

никакой магии и все явно

и все хорошо поддается статическому анализу

а конструктор который массивчик принимает - прощай информация о типах

тогда вообще от конструктора отличия не вижу