в чем польза в процессе разработки?

Эм?

Не понял вопрос

Эм?

ну ты сказал - "тайпхинты это польза в процессе разработки"

> а не ядром языка в этом случае у тебя будет вечный рассинхрон в том кто как что готовит.

ну ты сказал - "тайпхинты это польза в процессе разработки"

Да. Это возможность в нормальной ide получить автодополнение, подсветку и прочие плюшки кодинспектора

Да. Это возможность в нормальной ide получить автодополнение, подсветку и прочие плюшки кодинспектора

И сейчас их нет

И сейчас их нет

Ты в чем пишешь код?

В шторме

Да. Это возможность в нормальной ide получить автодополнение, подсветку и прочие плюшки кодинспектора

давай так, вот в семерке появился тайпхинт для возвращаемых значений и для скаляров. Ты этим пользуешься? Это можно было делать через phpdoc. так зачем по твоему их добавили?

Если пых

И там нет?

И там нет?

На днищенском уровне

И там нет?

опиши мне массив где ключ строка а значение User

и что бы шторм все мог подсказать

И желательно чтобы типы выводил, а не на каждый чих док коммент писать

или - задача со звездочкой - опиши мне массивчик с ключами ([id: string, name: string]) что бы работал автокомплит

И желательно чтобы типы выводил, а не на каждый чих док коммент писать

не ну шторм худо бедно выводит

не ну шторм худо бедно выводит

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

Мой падаван тоже выводит)

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

опиши мне массив где ключ строка а значение User

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

https://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Advanced+Metadata

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

о да, мы расширим phpdoc и волшебным образом шторм научится в комплит

И желательно чтобы типы выводил, а не на каждый чих док коммент писать

Не вижу в этом плохого. Особенно с учётом отслеживания ид-ёй цепочки

о да, мы расширим phpdoc и волшебным образом шторм научится в комплит

Так он умеет

Так он умеет

он умеет ровно столько сколько он умеет. вон введут в стандарт phpdocumentator описание массивчиков - и... что? пока разработчики шторма не реализуют поддержку оного не будет у тебя никаких комлитов.

Есть проект на старом сайлексе и первом пимпле. Отлично подсвечивается и автодополняет

Есть проект на старом сайлексе и первом пимпле. Отлично подсвечивается и автодополняет

то есть ты предлагаешь померяться кто на чем пишет и у кого проекты больше?)

У него просто нет проблем

он умеет ровно столько сколько он умеет. вон введут в стандарт phpdocumentator описание массивчиков - и... что? пока разработчики шторма не реализуют поддержку оного не будет у тебя никаких комлитов.

Ну вот я собственно об этом и спрашивал. Стоит ли замедление рантайме этих спорных плюшек на этапе разработки

Можно порадоваться ?

то есть ты предлагаешь померяться кто на чем пишет и у кого проекты больше?)

Нет. Всего лишь показал, что даже в не самом удобном исходном материале обсуждаемые фичи работают

ну то есть я не очень понимаю твою позицию: - ты не разработчик php и ни тебе поддерживать сорсы php - ты не пользуешься благами статической типизации (до уровня array<mixed, mixed>) и в целом тебе комфортно - окей, никто не заставляет тебя юзать новые фичи языка. - добавление дженериков позволит интерпритатору знать больше о том что он выполняет, так что в контексте какого-нибудь JIT может быть и профит по производительности

Нет. Всего лишь показал, что даже в не самом удобном исходном материале обсуждаемые фичи работают

"не самом удобном" - это каком? там где есть плагины написанные на java и чуть что надо допиливать?

да и потом о каком именно комплите в мимпл ты говоришь? типа подсказки $pimple->get()'?

ну то есть ты видимо не понимаешь основной проблемы....

ну и да, чисто для статистики - с какими еще языками ты плотно работал?

ну то есть ты видимо не понимаешь основной проблемы....

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

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

> Но считаю её не достаточным аргументом для утяжеления/замедления языка. так а в чем утяжеление/замедленее?

ну то есть больше синтаксиса - это опциональная штука. На твои проекты не повлияет. Замедленее - если его нет, тебе норм?

> Но считаю её не достаточным аргументом для утяжеления/замедления языка. так а в чем утяжеление/замедленее?

Любые дополнительные проверки увеличивают время выполнения кода

Любые дополнительные проверки увеличивают время выполнения кода

если проверки выполняются ДО выполнения - не увеличивают

Любые дополнительные проверки увеличивают время выполнения кода

Неверно абсолютно

Любые дополнительные проверки увеличивают время выполнения кода

ты пользуешься тайпхинтами для скаляров?

> Но считаю её не достаточным аргументом для утяжеления/замедления языка. так а в чем утяжеление/замедленее?

И все же... Если не обсуждать сейчас мою позицию, это все-таки субъективный момент, а ответить на вопрос. Есть ли у дженериков какие-то явные преимущества не относящиеся к качеству кода?

И все же... Если не обсуждать сейчас мою позицию, это все-таки субъективный момент, а ответить на вопрос. Есть ли у дженериков какие-то явные преимущества не относящиеся к качеству кода?

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

блин... серьёзно, люди в пхп обсуждают замедление кода от дженериков?) можно подумать он без них ракета)

будет ли пользоваться JIT (который будет в php8) преимуществами дополнительной интроспекции - это вопрос к разработчикам этого JIT. Но есть мнение что если на вход будет подаваться array<string> а не array то он может более специализированный код нагенерить

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

Извиняюсь за нудность. Не относящиеся к качеству кода.

Извиняюсь за нудность. Не относящиеся к качеству кода.

это не относится к КАЧЕСТВУ кода

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

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

что до ущерба производительности - стоимость проверки foo(array $bar) и foo(array<string> $bar) в целом одинаковая.

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

Услышал, но хотелось бы ещё доводов.

Услышал, но хотелось бы ещё доводов.

типа что можно еще с интроспекцией творить?))

Услышал, но хотелось бы ещё доводов.

то что это с jit позволит увеличить производительность - аргумент?

ну это все вытекает из возможностей интроспекции

типа что можно еще с интроспекцией творить?))

Нет, просто интроспекция != дженериков, разве нет?

Нет, просто интроспекция != дженериков, разве нет?

че?

ну мол.... интроспекцию можно делать и без дженериков?

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

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

ну он не понимает как да и возможно в его случае он профита реально не получит

основной аргумент - сейчас у тебя нет возможности описать параметризованные типы. Вообще. Даже в phpdoc. Только если свой формат и свое поведение выдумывать (как это сделали в phan/psalm). Дальше вопрос понимаешь ли ты что такое параметризованные типы

а как много у тебя в проектах кода который по факту работает (мог бы работать) с параметризованными типами, зависит от твоей "архитектуры". У меня такого кода много. Во фреймворках такого кода много.

ну вот мне не особо нравится идея со своими форматами. Сейчас по коду разбросано говно для псалма, скрутинайзера, пхпюнита и штормовской поделки... напрягает

ну вот мне не особо нравится идея со своими форматами. Сейчас по коду разбросано говно для псалма, скрутинайзера, пхпюнита и штормовской поделки... напрягает

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

в таких вещах очень важен единый источник правды

блин... серьёзно, люди в пхп обсуждают замедление кода от дженериков?) можно подумать он без них ракета)

Самый быстрый все таки из скриптовых языков, так что так се подъеб)

Самый быстрый все таки из скриптовых языков, так что так се подъеб)

lua?

Самый быстрый все таки из скриптовых языков, так что так се подъеб)

давно?)

lua?

Хз с ним не видел бенчмарков на самом дел

давно?)

С 7.1)

Пока вы висите в вашем евент лупе, пхп уже отстрелялся и умер

та не) пхп умирающее говно) ток бложики на битриксе пилить)

От безысходности

в таких вещах очень важен единый источник правды

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

та не) пхп умирающее говно) ток бложики на битриксе пилить)

Нет. Пхп хороший

Пока вы висите в вашем евент лупе, пхп уже отстрелялся и умер

https://i.redditmedia.com/sCosRQG-B43qL6O9_lVHJAnK4cZdiSF96dPMrqj_DAw.jpg?w=320&s=c5249938d372ea56811dbfe9408cf5b9

та не) пхп умирающее говно) ток бложики на битриксе пилить)

некоторые компании с тобой не согласны)

Нет. Пхп хороший

в тебе говорит стокгольмский синдром

некоторые компании с тобой не согласны)

http://iscience.ru/wp-content/uploads/2015/12/sarcasm21.jpg

Нет. Пхп хороший

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

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

ну то есть это вопрос о самокритике какой-нибудь

К остальному я привык

нету плохих языков, нету хороших...

есть инструменты и задачи :)

да лан) в плане быстро\качественно\дешево пхп неплох)

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

ну вот я тож структурный тайпинг хочу) как в го)

да лан) в плане быстро\качественно\дешево пхп неплох)

неплох - да, но далеко уже не лучший

ну вот я тож структурный тайпинг хочу) как в го)

коль уж пиздить из го, закажем ещё горутинки)

неплох - да, но далеко уже не лучший

а что значит лучший язык?)

да лан) в плане быстро\качественно\дешево пхп неплох)

В плане устроиться на работу с заибись зп при наличии минимума знаний так вообще без конкурентов)))

а что значит лучший язык?)

тот на котором ты еще не пишешь

коль уж пиздить из го, закажем ещё горутинки)

Но у нас же есть корутины

тот на котором ты еще не пишешь

и никогда не станешь)

основной аргумент - сейчас у тебя нет возможности описать параметризованные типы. Вообще. Даже в phpdoc. Только если свой формат и свое поведение выдумывать (как это сделали в phan/psalm). Дальше вопрос понимаешь ли ты что такое параметризованные типы

Это уже больше про жёсткую типизацию вообще. Ну да ладно, аргументы услышал, спасибо)