Saff
Michael Это решит проблему конечно, но меня не покидает чувство, что это костыль ) ИМХО Было бы правильно уметь обрабатывать типы возвращаемых значений без участия запроса. Ведь запросы может и не разработчик писать например.
Конечное решение пока крайне ужасное, через Query. Там не важно какой тип. Просто в слайсе все значения конкретных типов:
rows, errQuery := conn.Pool.Query(*qObject.Query)
...
rows.Next()
valueRaw, errValue := rows.Values()
...
value := fmt.Sprintf("%v", valueRaw[0])
Alexey
там где не хейтят за слово которое нельзя произносить? )
Daniel
в обоих
Daniel
и банят не за слово, а за попытку навязать его обмусоливание
aadz
надо для этого термина просто какое-то кодовое слово придумать, чтобы его не называть, а обсуждать проблему при админах... Типа, дети наркоту литературой, вроде, называют... :)
Daniel
да обсуждайте сколько хотите
aadz
А я не знаю, чего обсуждать. Я как-то и без этого слова в языке не не страдаю, вроде бы
aadz
Просто те, кто тоже не страдает, им и пофиг. Но есть страдальцы, что же поделаешь?
Alexey
я страдаю. но мне очень понравился дизайн. фактически могут завести тайпклассы.
aadz
А почему тогда сразу не юзать C++? Там все есть, что надо и не надо
Daniel
Просто те, кто тоже не страдает, им и пофиг. Но есть страдальцы, что же поделаешь?
от страдальцев требуется внятно изложить, по чему же они страдают
Alexey
если бы ко всем плюсам го добавить возможность решать ежедневные задачи без кодогенерации было бы очень круто
Daniel
если бы ко всем плюсам го добавить возможность решать ежедневные задачи без кодогенерации было бы очень круто
да что у вас за ежедневные задачи такие?
Alexey
да мы с тобой уже обсуждали. я не буду снова. тебе лень или ты предложишь кодогенерацию.
Daniel
обсуждали
aadz
Кстати, в С++ можно больше половины всех этих прелестей не использовать, а говнокодить не хуже других... Только проблема чужой код читать, где больше половины этих фич используется как раз. А в древности народ вообще на С писал, и хорошо получалось у многих...
Daniel
и, подумав, я решил, что тебе не генерики нужны, а типсуммы
Daniel
я прав?
Alexey
можно решить генериками
Michael
Michael Это решит проблему конечно, но меня не покидает чувство, что это костыль ) ИМХО Было бы правильно уметь обрабатывать типы возвращаемых значений без участия запроса. Ведь запросы может и не разработчик писать например.
Конечное решение пока крайне ужасное, через Query. Там не важно какой тип. Просто в слайсе все значения конкретных типов:
rows, errQuery := conn.Pool.Query(*qObject.Query)
...
rows.Next()
valueRaw, errValue := rows.Values()
...
value := fmt.Sprintf("%v", valueRaw[0])
То что можно сделать в сиквеле, сделай в сиквеле, в прикладном коде оставь форматирование вывода и не мучай свой мозг
Alexey
но в типах суммах все равно будет нужна параметризация. ты же не хочешь тип сумму писать на каждый тип значения в ней
Alexey
вот за это, как раз, генерики и хейтят те, кто понимает
ну пассивную агрессию мы уже тоже обсуждали, да?
Daniel
Daniel
я довольно активно агрессивен обычно
Daniel
тогда и не начинай, ок?
aadz
:)
Alexey
Просто каждый раз когда я получаю interface {} у меня возникает вопрос что там. И если это мой код, то еще есть шансы разобраться, но если это чужой, то все. Труба. Можно вокруг этого всего накостылить кодогенерацию и документацию, но в живом проекте поддержать это нереально :(
Alexey
И вопрос не в том чтобы узнать что там A или B. Вопрос в том, что там может быть массив или строка или хз вообще что. Вот каждый раз вместо этого я хочу видеть конкретный тип параметр.
Daniel
да откуда ты его так часто получаешь?
aadz
Просто каждый раз когда я получаю interface {} у меня возникает вопрос что там. И если это мой код, то еще есть шансы разобраться, но если это чужой, то все. Труба. Можно вокруг этого всего накостылить кодогенерацию и документацию, но в живом проекте поддержать это нереально :(
А как же ты тогда юзаешь ридеры с райтерами? Это же интерфейсы сплошные
Daniel
не, боль именно от пустого интерфейса
Daniel
который, конечно, та еще хрень
aadz
а... пустых я тоже боюся что-то
Pawel
Изо дня в день этот плачь Ярославны.
— без дженериков никак!
— приведи пример кода!
— ...
— без дженериков никак!
Pawel
тайпклассов нет
дада, в С++ они ох как нужны
Ты бы разобрался для начала что такое тайп классы и какой в С++ обощённое прграммирвоание
ttldtor
дада, в С++ они ох как нужны
Ты бы разобрался для начала что такое тайп классы и какой в С++ обощённое прграммирвоание
у меня более 10 лет опыта разработки приложений на плюсах, я знаю, что там нет тайп классов и не может быть)
ttldtor
даже трейтов нет
ttldtor
типа скаловских
ttldtor
или растовых
ttldtor
скоро будут концепты, но то не то)
Ευγένιος
В расте таже фигня.
Ευγένιος
Ими можно обмазываться.
Pawel
у меня более 10 лет опыта разработки приложений на плюсах, я знаю, что там нет тайп классов и не может быть)
ок.
Вот был вопрос "А почему тогда сразу не юзать C++? Там все есть, что надо и не надо"
ты говоришь - там тайпклассов нет. Отсюда можно сделать вывод что они там нужны.
ttldtor
накой в плюсах тайпклассы, если даже нормального вывода типов нет?)
ttldtor
как в хаскеле или в f#
Roman
ttldtor
я очень часто пишу код, помогающий компилятору понять, что он имеет дело не с переменной или указателем на функцию, а с типом...а вы про тайпклассы) Рано ещё, надо лет 20 подождать)
ttldtor
тогда во всех языках будет одно и то же
Pawel
накой в плюсах тайпклассы, если даже нормального вывода типов нет?)
это не с выводом типов связано. Тайп классы - это ограничения на дженерики, а вплюсах совершенно другой (уродский) механизм стат. полиморфизма, неимеющий с дженериками ничего общего
Алексей
Контракты воображаемого Go2 чем то очень отдалённо напоминают тайпклассы. Ну прям такое ощущение возникает.
ttldtor
я, кстати, достаточно недавно начал что-то писать на го и мне было очень тяжело после C++ и Java... это из-за того что у меня ООП мозга, да?
ttldtor
позабавило форматирование даты/времени)
doc
тогда во всех языках будет одно и то же
не будет же. будет долгая эволюционная замена одних другими
ttldtor
не будет же. будет долгая эволюционная замена одних другими
но Cobol даже всё ещё жив...как-то не заменяется...
ttldtor
это как с естественными языками
Алексей
ну это прям очень широкое определение
Алексей
по которому вообще почти все языки признаются живыми
Michael
После беглого прочтения черновика гоу2 генериков, показалось что это продолжение развития идеи, что генерики в ГОУ это интерфейсы
Чем сейчас плохо - не понятно, что черновики дадут лучшего вообще не ясно
Алексей
Дамы и господа, подскажите пожалуйста как разрешить ситуацию...
У меня пакет в котором методы "ловят" внешние сообщения допустим http... парст их и передает дальше другому пакету, в котором крутится в бесконечный цикл и делает важные дела... в него приходят данные и он там с ними варится... но наступает момент, когда ему надо отдать какую-то информацию во внешку, он должен отдать её пакету который могет это делать - который и работает с "внешкой"...
и у меня получается циклический импорт... мне надо из одного пакета вызывать определнные методы, и обратно... и я что-то голову сломал как тут разъехаться что бы не было циклического ипорта...
Алексей
После беглого прочтения черновика гоу2 генериков, показалось что это продолжение развития идеи, что генерики в ГОУ это интерфейсы
Чем сейчас плохо - не понятно, что черновики дадут лучшего вообще не ясно
Ну если бы генерики не отличались бы принципиально от интерфейсов, их бы и не пытались ввести
Michael
Ну если бы генерики не отличались бы принципиально от интерфейсов, их бы и не пытались ввести
То что оно отличается то понятно, вопрос - зачем оно такое надо и что реально оно решит
В том виде как сейчас оно добавит сложности и кол-во г...но кода увеличится
Daniel
После беглого прочтения черновика гоу2 генериков, показалось что это продолжение развития идеи, что генерики в ГОУ это интерфейсы
Чем сейчас плохо - не понятно, что черновики дадут лучшего вообще не ясно
чем плохо сейчас - понятно, нет параметрических типов, а они время от времени нужны.
мы умеем делать параметрические типы кодогенерацией, но внятного синтаксиса описания этих самых параметрических типов нет, поэтому кодогенерация существует за пределами экосистемы языка, и это неудобно
чем кончится внедрене генериков - тоже понятно, энтузиасты начнут делать на них пресловутые тип-суммы и прочее наследование. они всегда это делают с генериками...
Алексей
вот наследования точно не надо, тем более через генерики
и такие энтузиасты будут посылаться на три буквы моментально
Daniel
Алексей
но вообще как бы в черновике в overview есть разделы Problem и Goals