kostyaBro
kostyaBro
Зачем делать такой же язык как и раньше. А да, котлин тоже не считается
Rostislav
Ну как минимум, с других языков можно заимствовать хорошие практики
Rostislav
Котлин неплохой пример компиляции языков
kostyaBro
Котлин неплохой пример компиляции языков
Котлин взял вещи из java не потому что в java они хороши а потому что это язык над java
Akim
Ребят я вот изучаю го и столкнулся с какой то непонятной особенностью func vf(v any) { fmt.Println(v) fmt.Printf("%T\n", v) } func vf1(v any) { fmt.Println(v) fmt.Printf("%T\n", v) vf(v) } func main() { var v GetSymbolPriceTickerResponse vf1(&v) } Output: &[] *main.GetSymbolPriceTickerResponse &[] *main.GetSymbolPriceTickerRespons Все типы доступны в vf Чуть меняю код func vf1(v any) { fmt.Println(v) fmt.Printf("%T\n", v) vf(&v) // тут } func main() { var v GetSymbolPriceTickerResponse vf1(v) // и тут } Output: [] main.GetSymbolPriceTickerResponse 0xc00010a210 *interface {} В итоге тип стерся. Почему так работает?
kostyaBro
Холивар
Не холивар а аргумент в пользу того что котлин странный пример. Ибо эти два языка с одним бакграундом
kostyaBro
К тому же с обязательноц совместимостью в обе стороны
kostyaBro
Но в любом случае в начале нашего холивара ошибка
kostyaBro
Создай слайс интерфейсов, как в java, добавь туда объекты, как в java и все заработает
kostyaBro
Ты же создал слайс объектов
Rostislav
Но в любом случае в начале нашего холивара ошибка
Да, передать этот слайс в метод, принимающий слайс интерфейсов
kostyaBro
Ааа, дошло кажись
https://go.dev/play/p/566Xc6nsUPh
kostyaBro
Jvm, но не Java как языком
да, просто не знал как правильнее выразиться
kostyaBro
Ааа, дошло кажись
то же что и в java но без generics))))
kostyaBro
Спасибо)
Обращайтесь) Но да тут любят похаливарить, чуть истину не проебали>
kostyaBro
Я же выше показал что можно
kostyaBro
причем тут дженерики
kostyaBro
Кто нить сталкивался?
GetSymbolPriceTickerResponse что такое ?
Илья
а ты взял указатель на интерфейс
Rostislav
причем тут дженерики
Вплане, что нельзя передать слайс с типом реализации в метод, принимающий слайс с типом интерфейса без дженериков
Akim
GetSymbolPriceTickerResponse что такое ?
Это массив структур
Maks
На самом деле это более правильный подход.
Akim
Это массив структур
type PriceTicker struct { Symbol string json:"symbol" Price string json:"price" Time float64 json:"time" } type GetSymbolPriceTickerResponse []PriceTicker
kostyaBro
не суть тебе уже выше ответили)
kostyaBro
)
Maks
это старое шарповое))
Akim
а ты взял указатель на интерфейс
У меня в этом фрагменте нет интерфейсов
Maks
хоть я и не пишу на шарпе уже тыщу лет а пишу на пыхе, такой подход мне был больше всего по душе)
Maks
видимо для этого и придумали джинерики в го)
Maks
что бы можно было)
Maks
так я понял?
Кіт ✙
Maks
не, с ними тоже не выходит. Хм. Надо подумать над кейсом когда это может быть актуальной проблемой
kostyaBro
так я понял?
Скорее чтобы ком
kostyaBro
скорее чтобы комъюнити отебалось
Maks
Это считается достижением или шагом назад?
Это не является ни чем)) Просто фактом) Потому что язык всего лишь инструмент)
Akim
any))
Да, точно... А подскажи пожалуйста почему в этом фрагменте тип не теряется func main() { var v GetSymbolPriceTickerResponse var i interface{} = v p := &v // vf1(v) fmt.Println(i) fmt.Printf("%T\n", i) fmt.Println(p) fmt.Printf("%T\n", p) } Output { 0} main.GetSymbolPriceTickerResponse &{ 0} *main.GetSymbolPriceTickerResponse
kostyaBro
У меня в этом фрагменте нет интерфейсов
type any = interface{} это из исходников go
Илья
закинь на go.dev/play
Rostislav
А понял. Ну да. В java тоже нельзя)))🤷🏽‍♂️
бля, стыд. жестко затупил) сорян)
Maks
бля, стыд. жестко затупил) сорян)
Как раз хотел проверить))))
Rostislav
и я пздц был чет уверен, что можно)
Rostislav
долго не писал походу)
Maks
Вообще выглядит логично. Когда у тебя есть кейс что ты получаешь массив объектов одного типа а потом хочешь их передать почему то в функцию которая принимает интерфейс - то получается ты где то наговнокодил.
Rostislav
дада, все норм) эт я чет ебнулся)
Maks
Это получается одна функция будет вызываться в несвязанных местах совершенно. Если у тебя однотипные данные передавай массив. Если разнотипные то нужно создать этот слайс с данными
Akim
закинь на go.dev/play
Спасибо за помощь, щас вроде понятно. Пытаюсь в голове сделать выводы. Видимо указатель это нечто, хранящее значение и тип. Указатель может смотреть сразу на обьект, например на структуру p := new(TypeStruct), или на переменную. p := &v В первом случае тип в указатель попадает самой структуры, все просто. Во втором случае эксперементальным путем выясняется, что попадает не тип значения, а тип переменной.
Maks
но в пыхе такое бы прокатило)))))
Илья
поэтому и выводит
kostyaBro
Вообще выглядит логично. Когда у тебя есть кейс что ты получаешь массив объектов одного типа а потом хочешь их передать почему то в функцию которая принимает интерфейс - то получается ты где то наговнокодил.
тут прикол в том что функция принимает массив интерфейсов, а хочется передать массив с объектами но так да, это не проверить в compile time без зависмимых типов или дженериков
Maks
Ну так ты хочешь передать массив объектов. Вероятно ты всегда будешь это делать в одном месте и тебе там интерфейс не нужен.
Maks
Это архитектуру позволяет держать правильнее
Илья
Весь код в одном файле позволяет держать правильнее
Akim
поэтому и выводит
var v GetSymbolPriceTickerResponse var i interface{} = v p := &i Первая строка это указатель на тип?
Илья
первая строка с начала?
Илья
нет, объявление
Maks
в пыхе проверил. Прокатывает)
Akim
А тогда где я в интерфейс передаю указатель на тип. В fmt.Println?