А бигинт только с 67версии хрома

Слава богам

А бигинт только с 67версии хрома

Полифилы там

> Нельзя считать деньги!1! > Бери BigInt > Где перегрузка операторов?!? Нельзя считать деньги!1!

Полифилы там

Уверен, что прям для es3

Даже раньше

Скорее всего

Просто не приходилось проверять

Этой библиотеке 18 лет https://github.com/zerobias/leemon

Т.е. с 2000 года ведётся отсчёт)

Занимается в данный момент тем, что перемалывает 500 разрядные числа при генерации криптографического ключа в телеграме

Это когда шарпа не было что ли?

Ну и опять же. Bigint. В копейках считать? Или в чём?

И перегрузки!1!

Как вы без перегрузок деньги считать будете ну

Ну и опять же. Bigint. В копейках считать? Или в чём?

В чем нужно

Где вы видели такое вообще

У меня даже в уме перегрузка операторов между прочим

чет перегрузка немного от кол-ва сообщений

чет перегрузка немного от кол-ва сообщений

Да норм, я набросил

опять фпшники

Если кто-то вспоминает тот олдскульный compilation target, то это его проблемы

Ну можешь сюда, хоть Java GWT или C# подставить - ничего не изменится. Жс это все равно не язык.

опять фпшники

Не

Жсники

жсники === фпшники

Ну можешь сюда, хоть Java GWT или C# подставить - ничего не изменится. Жс это все равно не язык.

Я хз нафига ты про него вспомнил, мы тут приличные люди вообще то

Я хз нафига ты про него вспомнил, мы тут приличные люди вообще то

Приличные люди не считают жс нормальным языком

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

И не оскорбляют людей с иным мнением, между прочим

Короче ясно всё с тобой, набрасыватель)

Вопросов больше не имею

Я хз нафига ты про него вспомнил, мы тут приличные люди вообще то

Да можешь хоть Java GWT или KotlinJS подставить, это ничего не изменит. Жс все равно уровнем ниже (как асемблер для Си), с типами или без.

Вопросов больше не имею

Прийдет к тебе аналитик с адовой формулой расчета какого нить коэффициента финансовых показателей. А ты такой a.add(b).add(c)... Визуально мало похоже на арифметику. А мы же люди, человечки. Сидишь потом, читаешь такой код, плюёшь на него и пишешь на жаве какой нибудь. Тем более, что ту же ноду она уделает в хвост и в гриву.

> Визуально мало похоже на арифметику Душераздирающе

Хоть по IO хоть по CPU-bound

> Визуально мало похоже на арифметику Душераздирающе

Глазораздирающе

Стадия первая, отрицание

Суппортить потом такую сатану

С перегрузками тупо для денег

И не говори

Перегрузка денег ето хорошо

Прийдет к тебе аналитик с адовой формулой расчета какого нить коэффициента финансовых показателей. А ты такой a.add(b).add(c)... Визуально мало похоже на арифметику. А мы же люди, человечки. Сидишь потом, читаешь такой код, плюёшь на него и пишешь на жаве какой нибудь. Тем более, что ту же ноду она уделает в хвост и в гриву.

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

ты php-ник чтоли?

Да.

А ещё ЖСер.

И планирую быть растером.

Вектором

И планирую быть растером.

Го ещё попробуй

Странно что программистами никто не пробует быть...

Странно что программистами никто не пробует быть...

вот да)

Странно что программистами никто не пробует быть...

А что значит, быть программистом?

Писать на до диезе, судя по всему, достаточно

Надо уметь починить принтер!

Писать на до диезе, судя по всему, достаточно

Один До уж тогда? извините за оффтоп

Надо уметь починить принтер!

Цисочку поднять еще, BGP настроить, арч собрать, Kubernetes на 2к машин развернуть, патчить PostgeSQL, контрибутить в Lucene, писать RFC, играть на скрипке, писать стихи, летать на МКС, но самое главное - уметь переустановить винду. Без этого скила - ты ж не программист)

Цисочку поднять еще, BGP настроить, арч собрать, Kubernetes на 2к машин развернуть, патчить PostgeSQL, контрибутить в Lucene, писать RFC, играть на скрипке, писать стихи, летать на МКС, но самое главное - уметь переустановить винду. Без этого скила - ты ж не программист)

Все так

Но это уже уровень чуть выше

Подскажите, есть ли какие-нибудь best practises по созданию фикстур? Есть ли способ организовать механизм создания фикстур для большого объема тестов для большого количества сущностей со связями, не превращая это все в ад из огромной кучи методов и наследования?

Подскажите, есть ли какие-нибудь best practises по созданию фикстур? Есть ли способ организовать механизм создания фикстур для большого объема тестов для большого количества сущностей со связями, не превращая это все в ад из огромной кучи методов и наследования?

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

https://habr.com/company/mailru/blog/329494/

А вот скажите, насколько по вашему приведённые в статье аргументы действительно серьёзны? Как по мне - не очень. - хочу, быть всегда уверен, что у меня в массиве только экземпляры нужного мне класса; :это скорее вопрос архитектуры. Если у тебя массив набирается из где попало, то проблема не в отсутствии жёсткого контроля со стороны языка, а в непродуманном коде. - хочу автодополнение и подсветку в IDE; :в том же phpStorm эти фичи отлично работают из коробки при условии использования хотя бы самого базового phpDoc А тянуть в язык дополнительные конструкции только для того, чтобы позволить халатному разработчику дальше оставаться таким... имхо таке идея :-/

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

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

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

Не дороговато ли предотвращать ошибки невнимательности утяжелением языка?

А вот скажите, насколько по вашему приведённые в статье аргументы действительно серьёзны? Как по мне - не очень. - хочу, быть всегда уверен, что у меня в массиве только экземпляры нужного мне класса; :это скорее вопрос архитектуры. Если у тебя массив набирается из где попало, то проблема не в отсутствии жёсткого контроля со стороны языка, а в непродуманном коде. - хочу автодополнение и подсветку в IDE; :в том же phpStorm эти фичи отлично работают из коробки при условии использования хотя бы самого базового phpDoc А тянуть в язык дополнительные конструкции только для того, чтобы позволить халатному разработчику дальше оставаться таким... имхо таке идея :-/

> это скорее вопрос архитектуры ты в своей мысли не учитываешь факт того, что массивчики не только собираются где попало но еще и используются где попало (ты ж их не просто так собираешь), да и еще код имеет свойство изменяться, и нам хочется быстро убедиться что мы ничего не сломали. Да, мы можем руками просмотреть все места использования нашего массивчика но это занимает время, это человеческий фактор и в целом у меня есть чем заняться помимо этого. Потому я бы хотел иметь возможность автоматической проверки. В целом в phan/psalm поддержка дженериков есть, хотя это и не сильно помогает. > в том же phpStorm эти фичи отлично работают из коробки проблема в том что люди зацикливаются на коллекциях и радуются возможности написать Collection|Data[]. По факту же есть намного больше вариантов "параметризованных типов". Один из них, к примеру, это возможность описать какие-то процессоры данных: interface NodeVisitor<Node> { public function visit(Node $node); } class DataTransformer implements Transformer<Data> { public transform(Data $data) { } } ну и возможность интроспекции к этому, и сразу целый класс задач решается намного проще.

Не дороговато ли предотвращать ошибки невнимательности утяжелением языка?

а это сильное утяжеление? опять же - профит в том что в php это будет опциональной конструкцией.

но по факту дженерики это капля в море. Я был бы рад хотя бы им, хотя возможность описывать структуру массивов, структурный тайпинг и т.д. меня радуют больше. Но это скорее всего проще будет просто перестать писать на php

Не дороговато ли предотвращать ошибки невнимательности утяжелением языка?

То что это дорого для языка - проблемы самого языка

А использование параметризованных типов это ну базовая фича)

За которой кроется много чего интересного)

Если типизация отражается на рантайме по дефолту то что-то в языке идёт не так)

Если типизация отражается на рантайме по дефолту то что-то в языке идёт не так)

Это да(

> это скорее вопрос архитектуры ты в своей мысли не учитываешь факт того, что массивчики не только собираются где попало но еще и используются где попало (ты ж их не просто так собираешь), да и еще код имеет свойство изменяться, и нам хочется быстро убедиться что мы ничего не сломали. Да, мы можем руками просмотреть все места использования нашего массивчика но это занимает время, это человеческий фактор и в целом у меня есть чем заняться помимо этого. Потому я бы хотел иметь возможность автоматической проверки. В целом в phan/psalm поддержка дженериков есть, хотя это и не сильно помогает. > в том же phpStorm эти фичи отлично работают из коробки проблема в том что люди зацикливаются на коллекциях и радуются возможности написать Collection|Data[]. По факту же есть намного больше вариантов "параметризованных типов". Один из них, к примеру, это возможность описать какие-то процессоры данных: interface NodeVisitor<Node> { public function visit(Node $node); } class DataTransformer implements Transformer<Data> { public transform(Data $data) { } } ну и возможность интроспекции к этому, и сразу целый класс задач решается намного проще.

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

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

Усложнять я имею ввиду вводить конструкции, которые не ускоряют исполнение кода

мы ж не просим штуки вроде,... function array_column<T extends array>(iterable<T>, keyof T $key): T[$key]

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

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

более того, тайпхинты ЗАМеДЛЯЮТ код

выпилить

жесточайше

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

Ну вот тайпхинт через IDE на мой взгляд отлично решает свою задачу. О том и речь

Ну вот тайпхинт через IDE на мой взгляд отлично решает свою задачу. О том и речь

Ничего не понял)

Усложнять я имею ввиду вводить конструкции, которые не ускоряют исполнение кода

исполнение кода в плане стоимости это капейки. Если сравнить с трудозатратами на поддержку и написание кода. И если в языке можно организовать фичу которая позволяет удешивить поддержку/написание но при этом не скажется на производительности никак (ни ускорит ни замедлит) - то мне кажеся выбор очевиден.

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

Хаскель это язык для глупых людей, которые не в состояние в голове проверять композируемость своих объектов, то ли дело пых...

Ну вот тайпхинт через IDE на мой взгляд отлично решает свою задачу. О том и речь

О чем речь? О том что тебе никогда не хочется описать не просто array а Data[]? или там array<string, string> хотя бы?

или о том что ты никогда не пользовался статическим анализом?

О чем речь? О том что тебе никогда не хочется описать не просто array а Data[]? или там array<string, string> хотя бы?

Either<User, FailedAuth>

Ничего не понял)

Свайп) иметь ввиду, что тайпхинт это помольза в процессе разработки. И она отлично работает средствами иде. А рантайме, разумнее, имхо, фокусировки на производительности

Either<User, FailedAuth>

это к вопросу о опыте и воображении. Если человеку с массивчиками сложно то....

Свайп) иметь ввиду, что тайпхинт это помольза в процессе разработки. И она отлично работает средствами иде. А рантайме, разумнее, имхо, фокусировки на производительности

тайпхинты замедляют рантайм. Сама идея проверки типов в рантайме (которую нельзя выключить) это рак

это к вопросу о опыте и воображении. Если человеку с массивчиками сложно то....

Так ну не оч комфортно юзать все это, если потом надо руками везде тайпхинты ставить

Так ну не оч комфортно юзать все это, если потом надо руками везде тайпхинты ставить

ну без вывода типов да... не оч

ну без вывода типов да... не оч

А как его выводить, если такой тип невозможно описать в языке)

Свайп) иметь ввиду, что тайпхинт это помольза в процессе разработки. И она отлично работает средствами иде. А рантайме, разумнее, имхо, фокусировки на производительности

что такое свайп?

что такое свайп?

Клава

Свайп) иметь ввиду, что тайпхинт это помольза в процессе разработки. И она отлично работает средствами иде. А рантайме, разумнее, имхо, фокусировки на производительности

Так вот, парасетризация - это новая фича в тайпхинте

Свайп) иметь ввиду, что тайпхинт это помольза в процессе разработки. И она отлично работает средствами иде. А рантайме, разумнее, имхо, фокусировки на производительности

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

Еще нужны перечисления

попробуй на этот вопрос ответить

И еще бы вырубить рантайм...

Еще нужны перечисления

и все все что позволит красиво странспайлить пых в что-то другое)