ты не можешь интегрировать интерфейс в структуру. Интерфейс - это определение операторов, а структура определение данных. Они неким образом сообразуются, но не посредством встраивания одного в другое
Вот я и думаю, спасибо
Sergey
aadz
Alexander
Скорее всего, через интерфейс в структуре можно поиметь методы этого интерфейса из структуры
Alexander
А так вообще, в книжке по го описывалось как использовать интерфейсы в структуре, надо почитать, как это можно использовать
Sergey
Sergey
Почитаю
Artem
Вернусь к теме укоротителя ссылок
я вот за такой вариант, и его мапить с айди в базе
https://github.com/JackShadow/go-shorter/blob/master/common.go
l3xxxy
всем прив
l3xxxy
как дела
Fastumkruk
все так серьезно?
Alexey
Всего за месяц?) Компания 🦄 назревает?
Pavel
Это новый формат рекламы? 😅
Pavel
Не мы же 😂
JBáruch
Artem
ты не можешь интегрировать интерфейс в структуру. Интерфейс - это определение операторов, а структура определение данных. Они неким образом сообразуются, но не посредством встраивания одного в другое
Ну типо ты же в курсе да, что ты можешь встроить интерфейс в структуру, если хочешь. В стд либе много где встречается
aadz
что значит "встроить интерфейс в структуру"?
aadz
Ну типо ты же в курсе да, что ты можешь встроить интерфейс в структуру, если хочешь. В стд либе много где встречается
Покажи пример, пожалуйста, а то я, может быть, просто туплю
Artem
Покажи пример, пожалуйста, а то я, может быть, просто туплю
Держи
https://golang.org/src/context/context.go?#L317
Daniel
а зря
Artem
Ничего, я и не хотел объяснять
Daniel
там интерфейс заэмбежен в структуру
aadz
там где-то операции с данными встроены в структуру данных
aadz
?
Daniel
а?!
Daniel
какие операции с какими данными?
Daniel
в строке 317
aadz
блин.
aadz
мы о разном думали
aadz
Ну, может, я и не прав :(
aadz
да... это не вполне четко... Интерейс - это набор операторов, или данные. Или - вобще {}.
aadz
Но, по сути, в строке 317 - это данные. Указатель на некий Context
Daniel
нет
Daniel
интерфейс - это соглашение о вызовах
aadz
да
Daniel
за интерфейсом всегда прячется конкретный тип
Daniel
так вот - в структуру можно заэмбедить интерфейс
aadz
да
Daniel
инициализировать это поле надо будет так или иначе конкретным типом
aadz
наверное, я не был прав
Daniel
но нашему типу от заэмбеженого интерфейса достаются так же, как и от заэмбеженого типа, автоматически проброшенные вызовы
Daniel
и все
Daniel
никаких данных
Daniel
фактически, эмбеддинг - это синтакисческий сахар, нам не нужно писать нашему типу методы-обертки, которые будут звать методы поля
aadz
Блин, но фраза "интерфейс может быть полем в структуре" меня как-то напрягает... Надо будет, и правда, об этом подумать.
Daniel
и полем может быть
Daniel
интерфейс - это специальный вид указателя
aadz
Ну, OK!
aadz
Конечно, мы можем включать такой вид данных в структуру данных. Это я просто что-то не о том думал, или даже не слишком это все осознал. Сознаюсь!
aadz
Или кака-то фигня с терминологией. Я тупо не помню, как это все будет по-английски :( так что - не осознал, наверняка
.
Какой смысл встраивания интерфейса в структуру?
Leonid
Какой смысл встраивания интерфейса в структуру?
php может отдать данные как строкой, так и числом. Например.
freezlite
кто то сказал пхп ?
Leonid
Или ты сам хочешь передавать строку или число,DB или Tx
Leonid
Короче, вариантов несколько
Daniel
Поудалял содержательное
Anonymous
Такой вот вопрос.
Обычно при написании REST сервиса который работает с SQL базой данных свои запросы к базе держал в "модели"., сейчас вот задумался, если вынести из в отдельные .sql файлы и потом забирать из от туда.
Есть ли какие-либо best practices для этого? или уже готовые решения?
freezlite
в смысле из sql файлов
freezlite
в го читать sql файлы ? )
freezlite
из диска
freezlite
в процессе ?
Daniel
Вариантов больше одного
freezlite
:(
freezlite
а куда автор вопроса делся
Leonid
Такой вот вопрос.
Обычно при написании REST сервиса который работает с SQL базой данных свои запросы к базе держал в "модели"., сейчас вот задумался, если вынести из в отдельные .sql файлы и потом забирать из от туда.
Есть ли какие-либо best practices для этого? или уже готовые решения?
Смысла нет. Далеко ходить. Мы так пробовали.
Да ещё и голанд(да славится его имя вовеки) умеет подставлять имена, поля и прочне, так что лучше запросы поближе. Удобнее точно.
freezlite
запросы поближе ?
freezlite
набор текста не могу его понять
саша
Такой вот вопрос.
Обычно при написании REST сервиса который работает с SQL базой данных свои запросы к базе держал в "модели"., сейчас вот задумался, если вынести из в отдельные .sql файлы и потом забирать из от туда.
Есть ли какие-либо best practices для этого? или уже готовые решения?
А смысл? Го всё равно не умеет в компайл тайм включение содержимого файла.
Leonid
Да, ближе к месту использования.
Anonymous
из диска
нет, не из диска, просто запросы в разных пакете скажем sql лежат, извините сбил вас с толку
freezlite
сущность repositories
freezlite
туда запросы
freezlite
и интерфейс
freezlite
пакет repositories
freezlite
repositories/postgresql/
freezlite
например
саша
нет, не из диска, просто запросы в разных пакете скажем sql лежат, извините сбил вас с толку
не нужно отдельлного пакета для sql запросов, как максимум — выделить репозиторий из сервиса
freezlite
а в repositories/ интерфейсы