это потому что в php все плохо с типами, нет array shapes, нет туплов и всего того что уже давным давно есть в Hack

мне кажется с php все хорошо, если не забывать про PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.. думаю стоит подкорректировать свои ожидания, либо выбрать другой язык программирования в качестве основного (потому что человек перерос язык). у меня сейчас вот например страннейшее ощушение от чистого js, как будто бы попал в php4 времена

вроде так в питоне сделано с их тайп хинтами. нативный питон их тупо игнорит. а какой-нибудь mypy Уже чекает

мне кажется с php все хорошо, если не забывать про PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.. думаю стоит подкорректировать свои ожидания, либо выбрать другой язык программирования в качестве основного (потому что человек перерос язык). у меня сейчас вот например страннейшее ощушение от чистого js, как будто бы попал в php4 времена

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

вроде так в питоне сделано с их тайп хинтами. нативный питон их тупо игнорит. а какой-нибудь mypy Уже чекает

Для этого нужна опция выключения проверок тайпхинта в рантайме

Тогда и генерики легко завезти

вроде так в питоне сделано с их тайп хинтами. нативный питон их тупо игнорит. а какой-нибудь mypy Уже чекает

для php это будет означать неконсистентность языка (что не ново для него конечно). Когда у тебя часть описаний типов срабатывают в рантайме а часть - нет

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

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

да. все забыли, что пхп должен быть в лучшем случае 1 скрипт, который выплюнет тебе html-ку. теперь напридумывали всяких классов и вообще html на JS генерят.

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

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

да. все забыли, что пхп должен быть в лучшем случае 1 скрипт, который выплюнет тебе html-ку. теперь напридумывали всяких классов и вообще html на JS генерят.

дикари

Тогда и генерики легко завезти

в целом если так подумать.... есть компромисный вариант что бы и неконсистентностей было мало, и что бы расширять нормально. Типа... оставить текущее поведение для проверок в рантайме за счет упрощения типов. У тебя тип Foo[]|null - будет восприниматься как ?array

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

я против внедрения всего и вся из других ЯП, потому что у них есть. например за последнее время привнесли goto, spaceship operator из того, что сразу вспомнилось, что нафиг не нужно - но мы сделаем

я против внедрения всего и вся из других ЯП, потому что у них есть. например за последнее время привнесли goto, spaceship operator из того, что сразу вспомнилось, что нафиг не нужно - но мы сделаем

вчера как раз заюзал <=> - оч удобно)

я к своему стыду так и не знаю чё он делает(

goto - тоже удобно было когда писал таблицу переходов в примитивном компиляторе регулярок

я к своему стыду так и не знаю чё он делает(

if ($a > $b) return 1; if ($a < $b) return -1; return 0; аля такое. не помню когда плюс и когда минус, потому отдельный оператор норм

я против внедрения всего и вся из других ЯП, потому что у них есть. например за последнее время привнесли goto, spaceship operator из того, что сразу вспомнилось, что нафиг не нужно - но мы сделаем

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

вчера как раз заюзал <=> - оч удобно)

без отдельного оператора бы не справился?! ;) конечно бы написал, чуть длинне было бы, но написал бы.

без отдельного оператора бы не справился?! ;) конечно бы написал, чуть длинне было бы, но написал бы.

1. отдельный оператор упрощает это дело в разы 2. он никому не мешает и кушать не особо просит

if ($a > $b) return 1; if ($a < $b) return -1; return 0; аля такое. не помню когда плюс и когда минус, потому отдельный оператор норм

не было юзкейсов просто, посему и мимо прошёл)

не было юзкейсов просто, посему и мимо прошёл)

ну вот мне вчера надо было ивенты отсортировать по дате)

я к своему стыду так и не знаю чё он делает(

это вроде еще в перле было. сравнивает два числа и выплевывает -1 0 или 1 соответсвенно когда меньше равно или больше

не было юзкейсов просто, посему и мимо прошёл)

я забыл - а уже запилили либку которая позволяет писать что-то типа.... usort($arr, Sort::by(function (Event $event) { return $event->createdAt(); });

вот такие вот либки в целом бы устранили любую необходимость в отдельном операторе

но опять же - господ с WP на php 5.3 все еще хватает, им лучше оператор

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

без отдельного оператора бы не справился?! ;) конечно бы написал, чуть длинне было бы, но написал бы.

ну вот давай так... как ты относишься к фиче из php7.3 с возможностью дописывать запятую у последнего аргумента? foo( $a, $b, $c, );

деструктуризацию списков ты так же наверное призираешь: [$foo, $bar] = [$bar, $foo];

деструктуризацию списков ты так же наверное призираешь: [$foo, $bar] = [$bar, $foo];

я обожаю теперь [ 'foo' => $foo, 'bar' => $bar ] = ['foo' => 'Foo', 'bar' => 'Bar' ]

ну вот давай так... как ты относишься к фиче из php7.3 с возможностью дописывать запятую у последнего аргумента? foo( $a, $b, $c, );

не могу понять какую проблему это решает

не могу понять какую проблему это решает

git diff

git diff

foo($a,); - в данном случае не поможет, нужно КАРДИНАЛЬНО менять стиль написания кода

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

foo($a,); - в данном случае не поможет, нужно КАРДИНАЛЬНО менять стиль написания кода

с чем не поможет?

foo($a,); - в данном случае не поможет, нужно КАРДИНАЛЬНО менять стиль написания кода

но занятые в конце добавили именно для многострочных вызовов

foo($a,) foo($a, $b,) foo( $a, $b, $veryVeryVeryLoooooooooooooooooooong, ) foo( $a, $b, $veryVeryVeryLoooooooooooooooooooong, $profitHere, ) при написании кода я должен быть либо экстрасенсом, либо писать сразу так foo ( $a, )

Писать сразу

Писать сразу

у меня проект начат год, два, пять лет назад, откуда же я знал об этом :)

а если быть честным с собой: часто у вас столько аргументов, что бы это имело смысл?) не попытка ли это решить другую, более важную проблему, заметя под коврик?

а если быть честным с собой: часто у вас столько аргументов, что бы это имело смысл?) не попытка ли это решить другую, более важную проблему, заметя под коврик?

увы и ах - часто мгогострочность появляется и при двух аргументах

а если быть честным с собой: часто у вас столько аргументов, что бы это имело смысл?) не попытка ли это решить другую, более важную проблему, заметя под коврик?

обычно до 5 штук, описание типа + нормально названная переменная заставляют делать перенос строки на старые проблемы языка конечно все забивают. это и именование функций, порядок агрументов в них, будет ли аргумент передан по ссылке или нет (sort), super global массивы не являются обьектами

у меня проект начат год, два, пять лет назад, откуда же я знал об этом :)

Как жаль, что не существует способа пройти по проекту и поправить кодстайл, oh wait

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

увы и ах - часто мгогострочность появляется и при двух аргументах

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

а так, на лишнюю строку в гит диф аще насрать.

без нее лучше, конечно, ревьювится легче.. но можно и пережить

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

Какие конфликты, если код форматируется автоматически, але

Блейм можно выводить не по последнему изменению

без нее лучше, конечно, ревьювится легче.. но можно и пережить

оно справедливо, если ты просматриваешь 100500 изменений в сотне файлов. А если там пара-тройка - проблемы уже нет.

оно справедливо, если ты просматриваешь 100500 изменений в сотне файлов. А если там пара-тройка - проблемы уже нет.

бывает и такое при ревью, увы… ?

бывает и код на пхп4)

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

полное ревью по задаче делается явно не по дифам)

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

+

Какие конфликты, если код форматируется автоматически, але

ну ты понимаешь, что произойдет, если у тебя человек 20 работает над кодом и ты в какой-то момент пушишь реформатирование?

так что вполне себе в кассу

и по дифам тоже… ситуаций много бывает я обычно сначала по дифам, потом как возникает вопрос - переключаюсь в код

ну ты понимаешь, что произойдет, если у тебя человек 20 работает над кодом и ты в какой-то момент пушишь реформатирование?

да, знаю, потому что делал)

git checkout --ours && composer cs-fix

Уверен, что по --ours не сдохнет что-то из реальных конфликтов?

для этого уже тесты, проверки типов и так далее

и короткие веточки, конечно же

Давай проще, сколько разработчиков было в момент, когда решиди “полностью реформатировать код”?

@fes0r сколько нас разрабов?

с пыхом у нас только 4 работают по идее...

5

с фронтом поболее

с фронтом человек 10

и ты претир обновляешь))

проблем небыло

у меня так же небыло проблем с cs-fixer-ом в команде на 12 php-ников

и ты претир обновляешь))

это да)

просто пнул всех что бы заребейзились

и да - претир штука порадикальнее чем cs-fixer

потому все это - давно решенная проблема

еее, наконец-то я смогу делать как модные чуваки в js: array_reduce($arr, function ($res, $item) { return [...$res, $item->key => $item]; }, []);

Неужто, это читаемее чем array_reduce($arr, function ($res, $item) { $res[$item->key] = $item; return $res; }, []);Ну это субьективно. Да и работать должно на порядки быстрее.... хотя ху ноус

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

Неужто, это читаемее чем array_reduce($arr, function ($res, $item) { $res[$item->key] = $item; return $res; }, []);Ну это субьективно. Да и работать должно на порядки быстрее.... хотя ху ноус

работать быстрее оно не может потому что и так и так происходит полное копирование массива

ну мол... основные трудозатраты все же на перевыделение памяти

что до читабельности - тут все в привычки упирается. Если ты никогда не работал с подобным - скорее нет чем да. Если у тебя 50% времени на экране НЕ php - предпочтения могут быть уже другими. Опять же - фича опциональная - не хочешь, не юзай. Просто это к вопросу о консистентности.

работать быстрее оно не может потому что и так и так происходит полное копирование массива

Хмм... С каких пор вставка элемента это полное копирование в пыхе? $res[$item->key] = $item; Или я чего-то не знаю?

copy on write не?

Хмм... С каких пор вставка элемента это полное копирование в пыхе? $res[$item->key] = $item; Или я чего-то не знаю?

массивы в пыхе - значения. Изменение значения - копия + изменение.

copy on write это оптимизация которая позволяет не сразу копировать когда ты по значению передаешь штуки

ну именно здесь она и происходит

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

при передаче не трогали, при изменении надо копировать и менять

при передаче не трогали, при изменении надо копировать и менять

все так. имутабельность)

ну как... не совсем имутабельность...

но типа значения не меняются. могут лишь быть новыми

Хмм... С каких пор вставка элемента это полное копирование в пыхе? $res[$item->key] = $item; Или я чего-то не знаю?

создай массив на миллион элементов, добавь еще один - смотрим пиковое потребление памяти

при передаче не трогали, при изменении надо копировать и менять

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

создай массив на миллион элементов, добавь еще один - смотрим пиковое потребление памяти

Да ну, брешашь... пойду проверять

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

не важно передаем мы в функцию или нет - любое изменение массива - происходит полная копия

дальше все зависит от того насколько умные оптимизации под копотом

не важно передаем мы в функцию или нет - любое изменение массива - происходит полная копия

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

мол если она одна, то можно и не копировать

$a = range(1, 1000000); $b = $a; $b[] = 1000001;

2 копии