только говнокод стимулировать

+

дженерики нужнее

Можно долго обсуждать че нужнее, на самом деле

особенно когда речь про пхп

не сделаешь foo(string $a) и foo(int $a)…

а если сделаю?

фарт, ты мне друг или сундук? Если сделаешь, то сундук

ну потому что нельзя пока

foo(0); foo('0'); foo(false); ну скажи какие перегрузки должны юзаться и как это все дружит с жанглированием типами

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

статическая типизация + перегрузка методов

статическая типизация + перегрузка методов

тут строгая статическая нужна. Но тогда вопрос зачем вообще тебе статическая типизация.

да и вообще - если у тебя такие запросы - нафиг тебе php? есть Java есть kotlin есть c#

тут строгая статическая нужна. Но тогда вопрос зачем вообще тебе статическая типизация.

*сильная

у меня и так котлин

*сильная

да, заглючило

у меня и так котлин

ну так и все

?

перегрузка еще менее нужная

я был бы не против перегрузки операторов... можно было бы красивые DSL делать)))

но врядли доживу

welcome to ruby

ухожу ухожу

я был бы не против перегрузки операторов... можно было бы красивые DSL делать)))

зачем, зачем пыхе еще и это сделанное неправильно?

welcome to ruby

не, спасибо. Я типы хочу в этом соусе. И хороший вывод типов. То есть не не руби

зачем, зачем пыхе еще и это сделанное неправильно?

))) ну я ж хочу что бы правильно но

))) ну я ж хочу что бы правильно но

$a + $b ага, давай опишем общий случай

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

$a + $b ага, давай опишем общий случай

в python можно)

а если есть __toString() ?)

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

воу воу, не надо приводить вообще. не надо менять тип

т.е. ломаем пхп?

да!

ну сам понимаешь)

или.... фича доступна только если стоит use strict=1

т.е. ломаем всех в declare(strict=true)?)

тогда не вижу проблемы

т.е. ломаем всех в declare(strict=true)?)

там не ломается - там уже не будет кастов типов... а не... будет для операторов

бля

все плохо

declare(strict==true)

)))

declare(strict_for_real=true)

двойное равно смешнее

))))

#вопрос имеется код $this->handler_excel->parse() ->redirect(); Метод parse может вернуть не $this, а return;, т.е. null в случаи ошибки. Следующий метод идущий за ним зафаталится в этом случае, как быть? null->redirect(); будет..

Опять. "return;" это void

Опять. "return;" это void

спасибо

Опять. "return;" это void

void это отсутствие ретурна. Возможность написать return; при типе void это лишь "сахар" что бы ты имел возможность делать early return

void это отсутствие ретурна. Возможность написать return; при типе void это лишь "сахар" что бы ты имел возможность делать early return

void - это тип возвращаемого значения (в данном случе - возвращаемое значение должно отстутствовать), а не декларация об отсутствии какого-либо оператора. Прописать ": Generator" можно и без return в функции вообще, как пример. Ну, не суть - главное, что не null

void - это тип возвращаемого значения (в данном случе - возвращаемое значение должно отстутствовать), а не декларация об отсутствии какого-либо оператора. Прописать ": Generator" можно и без return в функции вообще, как пример. Ну, не суть - главное, что не null

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

это я к тому что void это НЕ тип данных. это пустое множество. Ничего. Нет ретурна. Явное указание что функция никогда ничего не вернет. Которое сам пых проверит в компайл тайме.

Имхо, стоит разделять понятие типа данных и понятие типа возвращаемого значения

Имхо, стоит разделять понятие типа данных и понятие типа возвращаемого значения

void - НЕ тип.

void это отсутствие типа

и нет не надо разделять "тип" и "тип"

Ещё осталось осмыслить, что тогда такое ?void

это я к тому что void это НЕ тип данных. это пустое множество. Ничего. Нет ретурна. Явное указание что функция никогда ничего не вернет. Которое сам пых проверит в компайл тайме.

Это не совсем так, функция, которая ничего не возвращает в пыхе это либо бросающая эксепшн, либо с бесконечным циклом

И void это все-таки тип)

Это не совсем так, функция, которая ничего не возвращает в пыхе это либо бросающая эксепшн, либо с бесконечным циклом

Но это к void отношения не имеет

Это не совсем так, функция, которая ничего не возвращает в пыхе это либо бросающая эксепшн, либо с бесконечным циклом

я к тому что void отличается от всего что есть в php тем что указание этого дела влияет на то, как компайлер реагирует на код. Если он видит что функция void и видит в коде return $someValue; то оно упадет.

ну то есть оно реально чекает не типы а синтаксис

я к тому что void отличается от всего что есть в php тем что указание этого дела влияет на то, как компайлер реагирует на код. Если он видит что функция void и видит в коде return $someValue; то оно упадет.

Да

ну то есть оно реально чекает не типы а синтаксис

Ты чё, это вывод

ну то есть оно реально чекает не типы а синтаксис

Будет чекать и типы, если там ?void

Ты чё, это вывод

но он не чекает тип вывода, он чекает что вывода нет

Будет чекать и типы, если там ?void

это проблема имплементации nullable

и конкретно void часть тут не фигурирует, просто у тебя нет другой возможности описать что функция возвращает null

но он не чекает тип вывода, он чекает что вывода нет

В данном случае этого достаточно)

вот была бы алгебра типов...

ERROR: S client not available

type FooBar = Foo | Bar | null

и что ж ты на пхп делаешь...)

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

напиши свой ?

напиши свой ?

Тупой шибко)

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

Не хочешь легаси затрагивать?

ну да, оно точно не пролезет

стат анализ выдернет свой код с сервера и убежит в шоке

На счет дифов не знаю, а игноры директорий/файлов можно наставить

Стат анализ без полного инспекта бесполезен ведь будет

ну хоть кодстайл

А всякие фиксеры - хер на них)

Приходится самому тут писать на базе ast дерева… но блин… так далеко не уехать

Хз. Как по мне, код стаил не является в проекте сколько-нибудь важным моментом. Разово фиксер прогнал, результат взял за точку отсчета и вперед: пущай перед комммтом все к 1 приводит

тяжко будет с блеймом работать…

Ну, свои велосипеды тоже не оч легко держать, так-то

Это т да… да и с дифом как-то нет идей как работать, если ast строить…

ID писать в формате id_* - что за… кто-то так еще пишет? поля в базе

ID писать в формате id_* - что за… кто-то так еще пишет? поля в базе

У нас на проекте вообще правило такое, все поля в таблице с префиксом самой таблицы, типа: members (member_id, member_name, member_password..) так мол джоины писать легче, ну и конечно исторически так сложилось)

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

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

1. код стайл лучше сразу применить ко всему коду. Если ты опасных трансформаций не делаешь то это безопасно. 2. если под код стайлом ты подразумеваешь что-то более жесткое - например никаких protected полей - то ты можешь сам замутить проверку на измененных файлах (но проверяться будут файлы целиком) - https://gist.github.com/fesor/05ea5add783382047b2cf0dbf0000099 3. если совсем надо что-то трекать эдакое - пишешь обертку которая берет номера строк которые были зааффекчены, и эксклудишь те штуки которые не в этих строчках. Сам.

У нас на проекте вообще правило такое, все поля в таблице с префиксом самой таблицы, типа: members (member_id, member_name, member_password..) так мол джоины писать легче, ну и конечно исторически так сложилось)

хз как это помогает, с таким подходом просто не юзать элиасы для имен таблиц и вжух SELECT member.id, member.name profile.some_info FROM member INNER JOIN profile ON profile.id=member.id

просто, схему проще читать, легко достигается

и не надо людям типа меня объяснять что за хуиту вы там придумали себе)

тяжко будет с блеймом работать…

git blame -w -M

причем шторм вроде как blame -w по умолчанию юзает.

а вот расскажите начинающему плиз: как вообще анализировать свой код? ну вот есть у меня проект на ларавеле/симфони/просто набор скриптов. Как мне найти в нем узкие места? какие бенчмарки? что вообще делать? этим профайлер должен заниматься?

есть ли "волшебный" пакет который по нажатию кнопки сделает хорошо?)

а вот расскажите начинающему плиз: как вообще анализировать свой код? ну вот есть у меня проект на ларавеле/симфони/просто набор скриптов. Как мне найти в нем узкие места? какие бенчмарки? что вообще делать? этим профайлер должен заниматься?

1. оптимизации требуются там где есть проблемы с производительностью. 2. нет проблем с производительностью - забей. 3. в большинстве ситуаций узким местом будут запросы в базу 3.1 отсутствие индексов, кривые запросы - это можно трекать слоулогом на продакшене и фиксить то что медленно 3.2 много маленьких повторяющихся запросов - опять же профайлер в случае симфони неплохо с обнаружением этого дела справляется 4. php-fpm предоставляет slow log так же, по которому можно трекать какие запросы были медленные что бы уже лазить профайлером 5. если у тебя есть деньги и проект представляет важность - можно заебашить какой сэмпловый профайлер на продакшене который будет тебе скидывать статистику (newrelic, tideways) - особенно хорошо когда у тебя легаси

и да - волшебный пакет называется "не болит не трогай"

можно поподробнее про слоулог?