а
Эта функция — метод типа Reader. Чтобы её использовать надо сначала создать Reader
https://golang.org/pkg/bufio/#Reader.ReadLine
https://golang.org/pkg/bufio/#Reader.ReadLine
rust_help -> rustgohelp
Size: a a a
2020 February 21
RS
как вы относитесь к определению интерфейса на стороне provider’а?
интерфейс у меня в главном пакете: https://github.com/romshark/eventlog/blob/master/eventlog/eventlog.go#L14
а имплементации в под-пакетах: https://github.com/romshark/eventlog/tree/master/eventlog
часто слышу что это антипаттерн и частично согласен, ведь интерфейс должен определяться на стороне потребителя а не на стороне производителя. Но в данном случае мне почему-то кажется оправданым данный подход
интерфейс у меня в главном пакете: https://github.com/romshark/eventlog/blob/master/eventlog/eventlog.go#L14
а имплементации в под-пакетах: https://github.com/romshark/eventlog/tree/master/eventlog
часто слышу что это антипаттерн и частично согласен, ведь интерфейс должен определяться на стороне потребителя а не на стороне производителя. Но в данном случае мне почему-то кажется оправданым данный подход
Y
Эта функция — метод типа Reader. Чтобы её использовать надо сначала создать Reader
https://golang.org/pkg/bufio/#Reader.ReadLine
https://golang.org/pkg/bufio/#Reader.ReadLine
там куча полей)
Y
type Reader struct {
buf []byte
rd io.Reader // reader provided by the client
r, w int // buf read and write positions
err error
lastByte int // last byte read for UnreadByte; -1 means invalid
lastRuneSize int // size of last rune read for UnreadRune; -1 means invalid
}
buf []byte
rd io.Reader // reader provided by the client
r, w int // buf read and write positions
err error
lastByte int // last byte read for UnreadByte; -1 means invalid
lastRuneSize int // size of last rune read for UnreadRune; -1 means invalid
}
а
YWNWA
type Reader struct {
buf []byte
rd io.Reader // reader provided by the client
r, w int // buf read and write positions
err error
lastByte int // last byte read for UnreadByte; -1 means invalid
lastRuneSize int // size of last rune read for UnreadRune; -1 means invalid
}
buf []byte
rd io.Reader // reader provided by the client
r, w int // buf read and write positions
err error
lastByte int // last byte read for UnreadByte; -1 means invalid
lastRuneSize int // size of last rune read for UnreadRune; -1 means invalid
}
они все приватные
AK
как вы относитесь к определению интерфейса на стороне provider’а?
интерфейс у меня в главном пакете: https://github.com/romshark/eventlog/blob/master/eventlog/eventlog.go#L14
а имплементации в под-пакетах: https://github.com/romshark/eventlog/tree/master/eventlog
часто слышу что это антипаттерн и частично согласен, ведь интерфейс должен определяться на стороне потребителя а не на стороне производителя. Но в данном случае мне почему-то кажется оправданым данный подход
интерфейс у меня в главном пакете: https://github.com/romshark/eventlog/blob/master/eventlog/eventlog.go#L14
а имплементации в под-пакетах: https://github.com/romshark/eventlog/tree/master/eventlog
часто слышу что это антипаттерн и частично согласен, ведь интерфейс должен определяться на стороне потребителя а не на стороне производителя. Но в данном случае мне почему-то кажется оправданым данный подход
IMHO по сути у интерфейсов есть 2 назначения:
1) Избавится от внешней зависимости, потребителем которой мы являемся (Определяем интерфейс на стороне потребителя).
2) Предоставить другим потребителям возможность изменить часть поведения нашего пакета (Определяем интерфейс у себя в пакете, и дефолтную реализацию рядом).
1) Избавится от внешней зависимости, потребителем которой мы являемся (Определяем интерфейс на стороне потребителя).
2) Предоставить другим потребителям возможность изменить часть поведения нашего пакета (Определяем интерфейс у себя в пакете, и дефолтную реализацию рядом).
DG
Всем привет.
Только начал знакомиться с Go и появилось пару вопросов, для которых, ответа нагуглить пока не удалось...
1. У gin есть возможность пройти циклом по параметрам из роута (range c.Params), есть ли подобная возможность для обхода query-параметров?
2. Есть ли возможность присвоить значение полю структуры, имея имя поля в переменной, т.е. что-то вроде:
fieldName := "myName"
structure[fieldName] = "text"
или это возможно сделать только через рефлекссию reflect.ValueOf(structure).FieldByName(fieldName).SetString("text")
Только начал знакомиться с Go и появилось пару вопросов, для которых, ответа нагуглить пока не удалось...
1. У gin есть возможность пройти циклом по параметрам из роута (range c.Params), есть ли подобная возможность для обхода query-параметров?
2. Есть ли возможность присвоить значение полю структуры, имея имя поля в переменной, т.е. что-то вроде:
fieldName := "myName"
structure[fieldName] = "text"
или это возможно сделать только через рефлекссию reflect.ValueOf(structure).FieldByName(fieldName).SetString("text")
RS
IMHO по сути у интерфейсов есть 2 назначения:
1) Избавится от внешней зависимости, потребителем которой мы являемся (Определяем интерфейс на стороне потребителя).
2) Предоставить другим потребителям возможность изменить часть поведения нашего пакета (Определяем интерфейс у себя в пакете, и дефолтную реализацию рядом).
1) Избавится от внешней зависимости, потребителем которой мы являемся (Определяем интерфейс на стороне потребителя).
2) Предоставить другим потребителям возможность изменить часть поведения нашего пакета (Определяем интерфейс у себя в пакете, и дефолтную реализацию рядом).
а если мы предоставляем некий API к которому прикладываем несколько имплементаций? это числится ко второму кейсу по твоему мнению?
RS
Всем привет.
Только начал знакомиться с Go и появилось пару вопросов, для которых, ответа нагуглить пока не удалось...
1. У gin есть возможность пройти циклом по параметрам из роута (range c.Params), есть ли подобная возможность для обхода query-параметров?
2. Есть ли возможность присвоить значение полю структуры, имея имя поля в переменной, т.е. что-то вроде:
fieldName := "myName"
structure[fieldName] = "text"
или это возможно сделать только через рефлекссию reflect.ValueOf(structure).FieldByName(fieldName).SetString("text")
Только начал знакомиться с Go и появилось пару вопросов, для которых, ответа нагуглить пока не удалось...
1. У gin есть возможность пройти циклом по параметрам из роута (range c.Params), есть ли подобная возможность для обхода query-параметров?
2. Есть ли возможность присвоить значение полю структуры, имея имя поля в переменной, т.е. что-то вроде:
fieldName := "myName"
structure[fieldName] = "text"
или это возможно сделать только через рефлекссию reflect.ValueOf(structure).FieldByName(fieldName).SetString("text")
> 2. Есть ли возможность присвоить значение полю структуры, имея имя поля в переменной, т.е. что-то вроде:
> fieldName := "myName"
> structure[fieldName] = "text"
нет. Но можно:
> fieldName := "myName"
> structure[fieldName] = "text"
нет. Но можно:
switch fieldName {
case ‘foo’:
s.Foo = v
case ‘bar’:
s.Bar = v
}AK
а если мы предоставляем некий API к которому прикладываем несколько имплементаций? это числится ко второму кейсу по твоему мнению?
Ну по сути ты ведь даешь клиентам точки расширения (ну или возможность выбора из нескольких вариантов или полной замены какой то части твоего кода). Думаю да, ко второму.
RS
Всем привет.
Только начал знакомиться с Go и появилось пару вопросов, для которых, ответа нагуглить пока не удалось...
1. У gin есть возможность пройти циклом по параметрам из роута (range c.Params), есть ли подобная возможность для обхода query-параметров?
2. Есть ли возможность присвоить значение полю структуры, имея имя поля в переменной, т.е. что-то вроде:
fieldName := "myName"
structure[fieldName] = "text"
или это возможно сделать только через рефлекссию reflect.ValueOf(structure).FieldByName(fieldName).SetString("text")
Только начал знакомиться с Go и появилось пару вопросов, для которых, ответа нагуглить пока не удалось...
1. У gin есть возможность пройти циклом по параметрам из роута (range c.Params), есть ли подобная возможность для обхода query-параметров?
2. Есть ли возможность присвоить значение полю структуры, имея имя поля в переменной, т.е. что-то вроде:
fieldName := "myName"
structure[fieldName] = "text"
или это возможно сделать только через рефлекссию reflect.ValueOf(structure).FieldByName(fieldName).SetString("text")
> или это возможно сделать только через рефлекссию
рефлексией стоит пользоваться только в самых крайних случаях, её скорее стоит избегать по многочисленным причинам (производительность, усложнение кода)
рефлексией стоит пользоваться только в самых крайних случаях, её скорее стоит избегать по многочисленным причинам (производительность, усложнение кода)
RS
Ну по сути ты ведь даешь клиентам точки расширения (ну или возможность выбора из нескольких вариантов или полной замены какой то части твоего кода). Думаю да, ко второму.
✌️🏻
DG
> или это возможно сделать только через рефлекссию
рефлексией стоит пользоваться только в самых крайних случаях, её скорее стоит избегать по многочисленным причинам (производительность, усложнение кода)
рефлексией стоит пользоваться только в самых крайних случаях, её скорее стоит избегать по многочисленным причинам (производительность, усложнение кода)
Понял, благодарю. Т.е. если у структуры пару десятков полей и нужно обновлять произвольные, значения которых будут браться из входящих данных, например json, то вполне нормально писать длиный switch с перечислением каждого поля, а не пытаться искать методов обновления полей в неком цикле с проверкой типа и т.д.?
RS
Понял, благодарю. Т.е. если у структуры пару десятков полей и нужно обновлять произвольные, значения которых будут браться из входящих данных, например json, то вполне нормально писать длиный switch с перечислением каждого поля, а не пытаться искать методов обновления полей в неком цикле с проверкой типа и т.д.?
у меня такое ощущение что что-то вы делаете не так
RS
Понял, благодарю. Т.е. если у структуры пару десятков полей и нужно обновлять произвольные, значения которых будут браться из входящих данных, например json, то вполне нормально писать длиный switch с перечислением каждого поля, а не пытаться искать методов обновления полей в неком цикле с проверкой типа и т.д.?
> а не пытаться искать методов обновления полей в неком цикле с проверкой типа и т.д.?
вот так точно не надо!
вот так точно не надо!