Pull to refresh

Comments 15

Сахарок на мой взгляд выглядит скорее запутаннее, к тому же. Этот стек вызовов функций в собственной голове переполняется ради понимания примитивного процесса получения аргументов (:
Синтаксический сахар вроде должен уменьшать количество кода и делать его проще, а тут как раз наоборот.
Ну уж нет. Синтаксический сахар почти всегда увеличивает количества кода. Вот количество текста в исходном коде — он должен уменьшать… и уменьшает…
Используем метод Роба Пайка, он довольно удобен в повседневном использовании. В плане производительности поисками таких вот блох обычно занимаются, когда всё остальное в проекте уже вылизано до блеска (т.е. никогда). Всегда находятся другие, более очевидные места, где можно подкрутить производительность
Это всё психология. Тот факт, что «всегда находятся другие, более очевидные места, где можно подкрутить производительность» просто-напросто обозначает, что 90% всех ресурсов ваша программа тратит просто на нагрев воздуха.

Если писать сразу с учётом всех этих «краевых» эффектов, то можно, как правило, создать программу, которая будет в 5-10 раз быстрее, но оно вам надо? Как правило ответ — «нет, не надо», возможность быстро менять программу при изменении требований важнее.

Но, собственно, Go на выжимание «всех соков» из процессора и не претендует — для этого C++ есть (хотя, в последнее время, rust начал на ту же нишу претендовать).
UFO just landed and posted this here
Лишний malloc на такую мелочь — вредно. По мне, любой синтаксический сахар должен писаться так, чтобы даже если весь код будет его использовать вместо оптимизированной версии, потери производительности были бы достаточно малы, чтобы можно было ими пренебречь, выиграв в скорости разработки. И я сильно сомневаюсь, что этот «сахар» его вообще даст.
Не путайте C++ и Go/Java/PHP/JavaScript/etc. Это в C++ стараются сделать «сахар» таким, чтобы компилятор мог его полностью «растворить». В другия языках часто «сахар» замедляет исполнение в десятки раз — но люди с этим мирятся ради гибкости.
Я учился программировать во времена, когда не во всяком ПК было 64 КБ памяти, поэтому для меня сегодняшние тенденции в наворачивании фреймворков на фреймворки ради скорости разработки — страшное расстройство. Другое дело, что скорость разработки нынче действительно требуется огромная, потому что конкурентов под каждым забором по пятеро, и все делают что-то вроде твоей программы, и кто первым выпустил, тот и победил, даже если в программе сделан только green path. Печально, но такова жизнь.
У вас что-то не так в коде, если вам нужно 10 аргументов в функции, тем более, не обзательных.

ЗЫ: не очень понятна постановка вопроса вообще, почему именно функциональные аргументы? Как же простота?

Для каждой задачи свой инструмент. Второй способ (функциональные аргументы) подразумевает что будет инициализироваться "сложный" со множеством параметров или "тяжелый" на ресурсы объект, который будет существовать на протяжении всей жизни программы или библиотеки. Тот же метод Dial упомянутый вами, обычно вызывается один раз. Также обычно функциональные аргументы используются только в Публичных методах/функциях. Если у вас внутренний апи, который вы вызываете тысячу раз, то применять там функциональные аргументы всегда плохая идея.
Кто-то выше писал что "Синтаксический сахар вроде должен уменьшать количество кода и делать его проще". Так и есть с точки зрения пользователя библиотеки, т.е. автору библиотеки таки да, надо написать чуть-чуть больше, в отличие от первого способа, чтобы конечному пользователю было легче жить.

Вроде как «третий вариант» это примерно то же, что в этой статье вариант с функциями, только функции у него принимают в первом аргументе этакий this для изменения, но при этом не находятся в кодовом пространстве класса, который призваны изменять. Да и не отражены там вопросы производительности вообще никак, только вопросы расширяемости, и в условиях динамически расширяемого API функции от this выглядят действительно удобнее — при добавлении фичи не нужно переписывать структуру *opts и код конструктора, а достаточно написать функцию для конфигурирования конкретного параметра.

PS: а что, если передавать в такой конструктор функцию от (*класс, ...int) или в крайнем случае ...string? Ещё гибче получается, причем второй аргумент функции оказывается опциональным списком — надо тебе, чтобы у фичи было много параметров, все запихиваешь в строки и передаешь, надо ноль — пишешь функцию от одного аргумента *класс, и хватит.
Sign up to leave a comment.

Articles