вот, а как они помечаются? я же справа просписал уже в ковычках, регистр влияет на экспорт поля?

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

<offtopic>Всегда хотелось узнать, где вы вот этого "в ковычках" понабрались?</offtopic>

<offtopic>Всегда хотелось узнать, где вы вот этого "в ковычках" понабрались?</offtopic>

теги же, так верно называется?)

теги же, так верно называется?)

Чего теги? Всегда "кавычки" в русском языке было

Кстати, а Теги в Go несут еще какие-либо функции, кроме помощи при рефлексии?

Ну можно и кастомной информацией их загрузить.

Кажется, тут могла бы быть структура

да

Хотя бы interface{}

неееет!!!

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

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

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

не надо так

не, я согласен, что лучше именованная структура

но неименованная лучше чем 20 параметром

лучше 20 параметров, чем пустой интерфейс

это хоть зарефакторить можно потом

ага, может ты еще винапи вспомнишь?

как классно было помнить, что между 2 и 3 аргументом нужно еще 3 нулла передать

как классно было помнить, что между 2 и 3 аргументом нужно еще 3 нулла передать

Обёртки даже не написали?

обертки — это уже что-то на уровне тех же именованных структур

еще раз, я не говорю, что пустой интерфейс — хорошо, я говорю, что 20 параметров — хуже

Нужно голосование. Я голосую за 20 параметров.

явное лучше

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

явное лучше

Java тут не место! ))

Господа, ну вы что Какие двадцать параметров Какие интерфейсы

Java тут не место! ))

Пайтон же

Используйте структуры и будет вам счастье

Используйте структуры и будет вам счастье

плюсую.

Как лучше передавать много параметров в функцию? Использовать структуру – 40 👍👍👍👍👍👍👍 83% Другое – 5 👍 10% Стопицот парметров - так и передавать. С группировкой по типам – 3 👍 6% Использовать interface{} ▫️ 0% 👥 48 people voted so far. Poll closed.

Java тут не место! ))

Блин, с опазданием понял шутку

есть вот такая спорная баянистая статья: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

есть вот такая спорная баянистая статья: https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

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

Фабрики параметров с фабриками объектов! С фабриками для первых двух фабрик

и фабриками фабрик первых двух фабрик

и фабриками фабрик первых двух фабрик

Не понял, прошу объяснить.

по фабрике на каждый параметр

Не понял, прошу объяснить.

больше фабрик хороших и разных

Похоже, что я не знаю, что такое "фабрика"...

Похоже, что я не знаю, что такое "фабрика"...

ну паттерн же

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

в джаве их много, ибо язык располагает

вот например в apache xml-rpc: https://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server/RequestProcessorFactoryFactory

В идеале, чтобы помимо дефолтных значений у аргументов, можно было бы еще вызывать функцию с именнованными аргументами. x := a(name="Adolf", age=13), а те что не заданы в функции использовали бы значения по умолчанию. Привет, Питон)

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

В идеале, чтобы помимо дефолтных значений у аргументов, можно было бы еще вызывать функцию с именнованными аргументами. x := a(name="Adolf", age=13), а те что не заданы в функции использовали бы значения по умолчанию. Привет, Питон)

x := a(params{name: "Adolf", age: 13}) Какие проблемы?

x := a(params{name: "Adolf", age: 13}) Какие проблемы?

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

x := a(params{name: "Adolf", age: 13}) Какие проблемы?

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

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

А какая разница?

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

params struct { a *int } // ... if p.a == nil { // use defaults, Luke }

params struct { a *int } // ... if p.a == nil { // use defaults, Luke }

тобишь если аргументов снова таки море, то должно быть море if'ов, шикарно)

А какая разница?

Например, в функции age равен нулю. Это пользователь передал 0 или он ничего не передал?

нет. хочешь — не делай if'ы. делай как хочешь, понимаешь? хоть рефлектом из мапы дефолты вгружай, хоть что

всем по-фи-гу.

Например, в функции age равен нулю. Это пользователь передал 0 или он ничего не передал?

Плюс еще, дефолтное значение может быть не обязательно дефолтным в системе. То есть, может мне нужен дефолтный age = 10)

нет. хочешь — не делай if'ы. делай как хочешь, понимаешь? хоть рефлектом из мапы дефолты вгружай, хоть что

зачем вообще влезать в разговор о том как передавать аргументы, если всем пофигу? :)

зачем вообще влезать в разговор о том как передавать аргументы, если всем пофигу? :)

затем, чтобы натолкнуть на мысль, что выбор всё равно останется за тем, как захотелось, а не за тем, как кто-то посоветовал)

затем, чтобы натолкнуть на мысль, что выбор всё равно останется за тем, как захотелось, а не за тем, как кто-то посоветовал)

и? зачем вообще что-то обсуждать тогда, выбор все равно остается за тобой)

и? зачем вообще что-то обсуждать тогда, выбор все равно остается за тобой)

вот я и не обсуждаю уже сколько времени 😁

Наставить на истинный путь пофигизма всех, кому не пофиг!

Наставить на истинный путь пофигизма всех, кому не пофиг!

Плюс еще, дефолтное значение может быть не обязательно дефолтным в системе. То есть, может мне нужен дефолтный age = 10)

Используй паттерн Builder

Используй паттерн Builder

Я думал об этом, но по мне тогда простота, к которой стремлюсь в данном пакете пропадет.

Я думал об этом, но по мне тогда простота, к которой стремлюсь в данном пакете пропадет.

Либо сложно, либо уродливо, впрочем ничего нового

Либо сложно, либо уродливо, впрочем ничего нового

как уже сказал - уродливо только пока нет оберток для функции)

Еще, к слову, очень не хватает перегрузки функций)

Еще, к слову, очень не хватает перегрузки функций)

Для чего?

Для чего?

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

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

Перегрузки - сомнительное счастье. Уж лучше это всё неймингом разрулить, как по мне, тк перегрузки это вообще не нужная фича, которая только язык усложняет

Перегрузки - сомнительное счастье. Уж лучше это всё неймингом разрулить, как по мне, тк перегрузки это вообще не нужная фича, которая только язык усложняет

По мне отличная альтернатива значениям по умолчанию и возможность использовал одно действие по разному. Уж точно лучше чем городить по сути одни функции, но с разными именами. А про усложняет язык разве что в реализации, уж читать и понимать исходники от этого сложнее точно не становится.

*Если делать с умом, разумеется. Но с умом надо все делать, иначе и if можно сделать такой, что язык усложняется, это же не повод отказываться от него

Так можно и до дженериков дойти. ))

кстати как справлятся без них?:

кстати как справлятся без них?:

писать функции под все варианты данных

По мне отличная альтернатива значениям по умолчанию и возможность использовал одно действие по разному. Уж точно лучше чем городить по сути одни функции, но с разными именами. А про усложняет язык разве что в реализации, уж читать и понимать исходники от этого сложнее точно не становится.

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

кстати как справлятся без них?:

Без дженериков? Кодогенерацией, ну или рефлексией