можно решить генериками

Michael Это решит проблему конечно, но меня не покидает чувство, что это костыль ) ИМХО Было бы правильно уметь обрабатывать типы возвращаемых значений без участия запроса. Ведь запросы может и не разработчик писать например. Конечное решение пока крайне ужасное, через Query. Там не важно какой тип. Просто в слайсе все значения конкретных типов: rows, errQuery := conn.Pool.Query(*qObject.Query) ... rows.Next() valueRaw, errValue := rows.Values() ... value := fmt.Sprintf("%v", valueRaw[0])

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

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

можно решить генериками

вот за это, как раз, генерики и хейтят те, кто понимает

вот за это, как раз, генерики и хейтят те, кто понимает

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

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

так и эдак придется

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

почему пассивную?

я довольно активно агрессивен обычно

почему пассивную?

не, в эту тему мы не будем скатываться.

тогда и не начинай, ок?

:)

Просто каждый раз когда я получаю interface {} у меня возникает вопрос что там. И если это мой код, то еще есть шансы разобраться, но если это чужой, то все. Труба. Можно вокруг этого всего накостылить кодогенерацию и документацию, но в живом проекте поддержать это нереально :(

И вопрос не в том чтобы узнать что там A или B. Вопрос в том, что там может быть массив или строка или хз вообще что. Вот каждый раз вместо этого я хочу видеть конкретный тип параметр.

да откуда ты его так часто получаешь?

Просто каждый раз когда я получаю interface {} у меня возникает вопрос что там. И если это мой код, то еще есть шансы разобраться, но если это чужой, то все. Труба. Можно вокруг этого всего накостылить кодогенерацию и документацию, но в живом проекте поддержать это нереально :(

А как же ты тогда юзаешь ридеры с райтерами? Это же интерфейсы сплошные

не, боль именно от пустого интерфейса

который, конечно, та еще хрень

не, боль именно от пустого интерфейса

именно так

а... пустых я тоже боюся что-то

Изо дня в день этот плачь Ярославны. — без дженериков никак! — приведи пример кода! — ... — без дженериков никак!

тайпклассов нет

дада, в С++ они ох как нужны Ты бы разобрался для начала что такое тайп классы и какой в С++ обощённое прграммирвоание

дада, в С++ они ох как нужны Ты бы разобрался для начала что такое тайп классы и какой в С++ обощённое прграммирвоание

у меня более 10 лет опыта разработки приложений на плюсах, я знаю, что там нет тайп классов и не может быть)

даже трейтов нет

типа скаловских

или растовых

скоро будут концепты, но то не то)

типа скаловских

Скаловские трейты то крутые интерфейсы.

В расте таже фигня.

Ими можно обмазываться.

у меня более 10 лет опыта разработки приложений на плюсах, я знаю, что там нет тайп классов и не может быть)

ок. Вот был вопрос "А почему тогда сразу не юзать C++? Там все есть, что надо и не надо" ты говоришь - там тайпклассов нет. Отсюда можно сделать вывод что они там нужны.

накой в плюсах тайпклассы, если даже нормального вывода типов нет?)

как в хаскеле или в f#

Кстати, в С++ можно больше половины всех этих прелестей не использовать, а говнокодить не хуже других... Только проблема чужой код читать, где больше половины этих фич используется как раз. А в древности народ вообще на С писал, и хорошо получалось у многих...

И получалось плохо

я очень часто пишу код, помогающий компилятору понять, что он имеет дело не с переменной или указателем на функцию, а с типом...а вы про тайпклассы) Рано ещё, надо лет 20 подождать)

тогда во всех языках будет одно и то же

накой в плюсах тайпклассы, если даже нормального вывода типов нет?)

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

накой в плюсах тайпклассы, если даже нормального вывода типов нет?)

Или в той же скале.

И получалось плохо

в С++ плохо абсолютно всё

в С++ плохо абсолютно всё

ну так Страустропу захотелось и Степанов помог)

Контракты воображаемого Go2 чем то очень отдалённо напоминают тайпклассы. Ну прям такое ощущение возникает.

я, кстати, достаточно недавно начал что-то писать на го и мне было очень тяжело после C++ и Java... это из-за того что у меня ООП мозга, да?

позабавило форматирование даты/времени)

тогда во всех языках будет одно и то же

не будет же. будет долгая эволюционная замена одних другими

не будет же. будет долгая эволюционная замена одних другими

но Cobol даже всё ещё жив...как-то не заменяется...

но Cobol даже всё ещё жив...как-то не заменяется...

это смотря что жизнью считать

это смотря что жизнью считать

ну, пока жив хотя бы один программист)...

это как с естественными языками

ну это прям очень широкое определение

по которому вообще почти все языки признаются живыми

После беглого прочтения черновика гоу2 генериков, показалось что это продолжение развития идеи, что генерики в ГОУ это интерфейсы Чем сейчас плохо - не понятно, что черновики дадут лучшего вообще не ясно

Дамы и господа, подскажите пожалуйста как разрешить ситуацию... У меня пакет в котором методы "ловят" внешние сообщения допустим http... парст их и передает дальше другому пакету, в котором крутится в бесконечный цикл и делает важные дела... в него приходят данные и он там с ними варится... но наступает момент, когда ему надо отдать какую-то информацию во внешку, он должен отдать её пакету который могет это делать - который и работает с "внешкой"... и у меня получается циклический импорт... мне надо из одного пакета вызывать определнные методы, и обратно... и я что-то голову сломал как тут разъехаться что бы не было циклического ипорта...

После беглого прочтения черновика гоу2 генериков, показалось что это продолжение развития идеи, что генерики в ГОУ это интерфейсы Чем сейчас плохо - не понятно, что черновики дадут лучшего вообще не ясно

Ну если бы генерики не отличались бы принципиально от интерфейсов, их бы и не пытались ввести

Ну если бы генерики не отличались бы принципиально от интерфейсов, их бы и не пытались ввести

То что оно отличается то понятно, вопрос - зачем оно такое надо и что реально оно решит В том виде как сейчас оно добавит сложности и кол-во г...но кода увеличится

После беглого прочтения черновика гоу2 генериков, показалось что это продолжение развития идеи, что генерики в ГОУ это интерфейсы Чем сейчас плохо - не понятно, что черновики дадут лучшего вообще не ясно

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

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

Дамы и господа, подскажите пожалуйста как разрешить ситуацию... У меня пакет в котором методы "ловят" внешние сообщения допустим http... парст их и передает дальше другому пакету, в котором крутится в бесконечный цикл и делает важные дела... в него приходят данные и он там с ними варится... но наступает момент, когда ему надо отдать какую-то информацию во внешку, он должен отдать её пакету который могет это делать - который и работает с "внешкой"... и у меня получается циклический импорт... мне надо из одного пакета вызывать определнные методы, и обратно... и я что-то голову сломал как тут разъехаться что бы не было циклического ипорта...

методы унести в третий пакет

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

не верю. их тупо больше...

но вообще как бы в черновике в overview есть разделы Problem и Goals

не верю. их тупо больше...

Ну давайте тогда все unsafe операции запретим, чтобы чудаки себе и другим в ноги не стреляли

а я бы и запретил, будь моя воля

а ну понятно

а я бы и запретил, будь моя воля

И сломал бы мне тонну проектов

ну - бодливой корове бог рог не дает

методы унести в третий пакет

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

ещё тьюринг полноту надо запретить, чтобы бесконечные циклы никто создать не смог

Ваще круто было бы ?

Ну давайте тогда все unsafe операции запретим, чтобы чудаки себе и другим в ноги не стреляли

С ума сошел?

ERROR: S client not available

С ума сошел?

нет, просто довёл идею до абсурда

Вот чего стоит сделать с unsafe - это сделать блоки кода

И ещё очень хочется свои коллекции вместо стандартных

а зачем?

мне вот не хочется :)

И ещё очень хочется свои коллекции вместо стандартных

если в 2.0 угодить всем любителям странного, эдак можно и руст переплюнуть

методы унести в третий пакет

Это ничем не помогает, только теперь в цепочке импортов появляется 3 пакет, получается что два других ипортят его, а он импортит оба... а при разносе на 4 пакета я получил крговую зависимость...

Это ничем не помогает, только теперь в цепочке импортов появляется 3 пакет, получается что два других ипортят его, а он импортит оба... а при разносе на 4 пакета я получил крговую зависимость...

А в GO нет чего-то похожего на плюсовую #pragma once ?

коллега

что вам не помогает

А в GO нет чего-то похожего на плюсовую #pragma once ?

Передавай в туда in/out каналы и пуляйся данными

да причем тут каналы

человек схему типов сдизайнить не може без циклических зависимостей

а вы ему каналы

что вам не помогает

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

Или Вы предлогами вынести вызываемый метод в другой пакет?...

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

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

я поначалу тоже о подобное спотыкался

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

Есть пакет отвечающий за работу с клиентами через вебсокеты, он в себе содержит логику према и отправки сообщений, и есть другой пакет, центральная логика, которая должна принимать в себя сообщения которые даёт пакет отвечающий за прием сообщений, и он же способен сам генирить сообщения которые должен отдавать пакету отвечающему за работу с клиентами по вебсокетам... Я при таком раскладе вижу два варианта, или разделить логикой пакета работающего с сокетами на две или спилить брокер сообщений и общаться через него...

а чем каналы плохо? :)

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

нет

раздели логику и данные

если в 2.0 угодить всем любителям странного, эдак можно и руст переплюнуть

А что странного?

ну, примитивный пример из головы: - есть пакет DB, оперирующий общением с БД. Конект, дисконект, ещё что-то - есть пакет с бизнес-логикой - есть данные, которые должны быть доступны обоим пакетам (сами данные, их структуры): модели/описания таблиц собственно, выносишь модели в отдельный пакет - и импортишь его куда угодно. Главное, чтобы в нём не было _вообще_ ничего лишнего: это тупо структуры, которые ничего не знают ни про БД, ни про логику

у тебя, например (ну пальцем в небо, не зная твоей начинки) - сделать отдельные структуры "UserMessage", "UserResponse", которые пулять по каналам в ядро и обратно

А что странного?

на сколько я понимаю, стандартные контейнеры устраивают всех кроме вас и может быть ещё пары тройки людей

у тебя, например (ну пальцем в небо, не зная твоей начинки) - сделать отдельные структуры "UserMessage", "UserResponse", которые пулять по каналам в ядро и обратно

Пока не получается осознать как это должно работать... Про вынесение данных - понятно, и то что их ипортить можно куда угодно тоже понятно... Но как тут должны работать каналы, я не совсем понимаю...

эм... а что именно непонятно?)

создаёшь 2 канала (ин, аут) или один (ин/аут) ; из "общателя" передаёшь в ядро, или наоборот, или в оба при инициализации дальше обоими пакетами слушаешь эти каналы, при поступлении данных - что-то с ними делаешь

Пока не получается осознать как это должно работать... Про вынесение данных - понятно, и то что их ипортить можно куда угодно тоже понятно... Но как тут должны работать каналы, я не совсем понимаю...

Тот же самый брокер, только вместо редиса с sub/pub у тебя просто ин/аут канал

создаёшь 2 канала (ин, аут) или один (ин/аут) ; из "общателя" передаёшь в ядро, или наоборот, или в оба при инициализации дальше обоими пакетами слушаешь эти каналы, при поступлении данных - что-то с ними делаешь

Солидарен