Olzhas
@madgopher запили сваггер под греймворк
Daniel
У тебя в проекте лежат функции вида func GenerateMyGenerator(*gen.Context) {
...
}
ну я обычно, когда пишу свой генератор, кладу его main.go где-то в проект, а в go:generate пишу go run path/main.go
Мерль
У тебя в проекте лежат функции вида func GenerateMyGenerator(*gen.Context) {
...
}
Которые вещаются как обработчики на конкретные типы например
Roman
как относитесь к implicit конвертации non-const в const например в случае возвращения из функции?
func CreateList(size int) const []string {
newSlice := make([]string, size)
for i := 0; i < size; i++ {
newSlice[i] = "sample text"
}
// newSlice is implicitly converted
// from "[]string" to "const []string"
return newSlice
}
Мерль
ну я обычно, когда пишу свой генератор, кладу его main.go где-то в проект, а в go:generate пишу go run path/main.go
Да, но только с нативной поддержкой
Вместо парсинга и тд пишется одна функция, на вход которой подаётся кусок AST
И которая запускается если только отслеживаемые места кода изменятся
Daniel
ааа, вот чего ты хочешь! не забыть генерацию толкнуть!
это да, это частая проблема
Мерль
ааа, вот чего ты хочешь! не забыть генерацию толкнуть!
это да, это частая проблема
В том числе
Так автоматически получаем версионирование кодогенераторов, и они не в виде стремных бинарников, собираемых из vendor
Так глядишь нормальная экосистема кодгена появится
Daniel
и тут-то нам и нагенерят наши коллеги почитать всякого...
Мерль
А генеренный код не надо читать
Мерль
И править
Daniel
как появится "нормальная экосистема" - так придется читать :(
Sergey
Мерль
как появится "нормальная экосистема" - так придется читать :(
Ну если вы активно работаете с чужими кодогенераторами, то уже больно
А так хоть какие то общие стандарты
Мерль
Кстати это неплохой способ завести типы суммы, не меняя язык
aadz
как относитесь к implicit конвертации non-const в const например в случае возвращения из функции?
func CreateList(size int) const []string {
newSlice := make([]string, size)
for i := 0; i < size; i++ {
newSlice[i] = "sample text"
}
// newSlice is implicitly converted
// from "[]string" to "const []string"
return newSlice
}
я к новым implicit делам вобще плохо отношусь. И в данном случае - тоже
Daniel
Кстати это неплохой способ завести типы суммы, не меняя язык
это как это?!
я знаю один способ - на интерфейсах и тайпсвитче.
Roman
я к новым implicit делам вобще плохо отношусь. И в данном случае - тоже
но тогда ведь придётся писать:
return const(newSlice)
не слишком ли это overhead'но?
Я предполагаю что implicitly кастить не-const в const - не опасно. Опасно кастить const в не-const imlicitly!
Roman
я бы даже сказал что кстатиь const в не-const должно быть невозможно и в таком случае implicit cast не-const в const будет, по моему, уместен
aadz
но тогда ведь придётся писать:
return const(newSlice)
не слишком ли это overhead'но?
Я предполагаю что implicitly кастить не-const в const - не опасно. Опасно кастить const в не-const imlicitly!
А что делать с функциями, которые и вызывают только для того, чтобы получить от них объект для дальнейшей работы с ним?
Roman
А что делать с функциями, которые и вызывают только для того, чтобы получить от них объект для дальнейшей работы с ним?
можно плиз краткий пример? 🙂 дабы не гадать что конкретно ты имеешь ввиду
Daniel
aadz
Например, тупо, функция make([]interface{})
😆или типа того
Daniel
я вот за эксплицитное всегда
aadz
Причина в том, чето если что-то делается, то не надо делать это по-тихому. Явное гораздо отчетливей, и часто лучше
Мерль
это как это?!
я знаю один способ - на интерфейсах и тайпсвитче.
Вот это самое, но только под капотом
Ведь, если сделать как я говорю, то нет разницы между линтером и кодогенератором
Сначала он генерирует набор типов обёрток для интерфейса mySumType, а потом проверяет валидность использования: чтобы не вернуть nil вместо mySumType, в type switch должны быть проверены все варианты, либо есть default
Мерль
И тд
Roman
Причина в том, чето если что-то делается, то не надо делать это по-тихому. Явное гораздо отчетливей, и часто лучше
ну хотя да... это предотвратит то, что мы можем случайно вернуть тот слайс как const, на который у нас есть mutable reference
aadz
ну хотя да... это предотвратит то, что мы можем случайно вернуть тот слайс как const, на который у нас есть mutable reference
Пропозал твой прочитал. Добавить мне нечего, кроме уже скаанного. Хочу слово const, :)
aadz
В смысле, слово уже есть, но хочу больше const, короче :)
aadz
Ну, уже есть такое ключевое слово. Но хочу, чтобы оно больше было похоже на const из плюсов
Roman
Roman
я там кстати ещё вопрос по поводу констант vs имутабельных символов разобрал только-что: https://github.com/romshark/Go-2-Proposal---Immutability#35-how-are-constants-different-from-immutables
aadz
Кстати, кажется, что по логике Go должно быть не varName const []string), а наоборот - varName []string const) 😄
aadz
я там кстати ещё вопрос по поводу констант vs имутабельных символов разобрал только-что: https://github.com/romshark/Go-2-Proposal---Immutability#35-how-are-constants-different-from-immutables
Блин, так бы хотелось, чтобы все было обругано на этапе компиляции, если надо, а не по ходу работы по разным памятям раскладывать потом и получать паники нафиг
Roman
aadz
потому что паники
aadz
или ты тоже экстемист-параноик и все подрят тестируешь, как маньяк какой-то? :)
Roman
потому что паники
я про обратный порядок декларации, т.е. не const []string а []string const, зачем?
Roman
как в таком случае описать const [] const *Object ?
Michael
const [] const * const Object
aadz
Ехал констант через констант
Видит констант в констант констант
Сунул констант констант в констант
Конст за констант констант цап
Daniel
я все же думаю, что const контейнера должен распространяться и на содержимое
Daniel
но!
Daniel
с моей точки зрения const модификатор не типа, но экземпляра
aadz
Ну, вобще-то да. Уж если мы говорим что контейнер не меняется, то это как раз по поводу содержимого и речь
aadz
И вобще, даже при косвенном доступе (любых степеней вложенности) объект, объявленный как конст, или его часть. не может по идее быть lvalue
Daniel
это тут уже было сегодня дважды
Roman
я все же думаю, что const контейнера должен распространяться и на содержимое
да, в этом есть смысл.
если учесть что slice это всего лишь
type slice struct {
p *[n]array
}
тогда поля const object'а должны быть тоже const
type Object struct {
Parent *Object
}
func main() {
const o := &Object{}
o.Parent = &Object{} // Compile-time error
o.NonConstMethod() // Compile-time error
o.Parent.NonConstMethod() // Compile-time error
}
в чём, собственно, есть смысл.
Roman
я все же думаю, что const контейнера должен распространяться и на содержимое
однако, что если нам нужен мутабельный слайс немутабельных объектов?
Wingman
в го же планируют вводить check/handle паттерны?
Daniel
однако, что если нам нужен мутабельный слайс немутабельных объектов?
с моей точки зрения const модификатор не типа, но экземпляра
Wingman
чего вы так упарываетесь по "аа мы всё сломаем, нельзя новые кейворды"? чек/хендл сломает в 100500 раз больше, чем какой-нибудь mut :)
Daniel
чек-хендл придумал кокс, и у него серьезные шансы попасть в язык
Daniel
а const придумал Роман (не целиком, но этот конкретный пропозал), и у него шансов мало, разве что он всем вот прям понравится-понравится
Wingman
Ясно :)
Daniel
я вот все же думаю, что начинать надо с комментов-аннотаций, и линтера
aadz
чего вы так упарываетесь по "аа мы всё сломаем, нельзя новые кейворды"? чек/хендл сломает в 100500 раз больше, чем какой-нибудь mut :)
почему сломает? Просто не будет комплироваться старыми компиляторами. А проверять ошибки, как и раньше, никто запретить не может
Roman
а const придумал Роман (не целиком, но этот конкретный пропозал), и у него шансов мало, разве что он всем вот прям понравится-понравится
да уж))
const скорее придумал Stroustrup (или откуда он там взялся) в C++, я лишь пытаюсь грамотно перевести его в Go
Wingman
почему сломает? Просто не будет комплироваться старыми компиляторами. А проверять ошибки, как и раньше, никто запретить не может
Ну о том тут и речь уже 2..3 дня, "нельзя новые кейворды для беквард компат."
Anonymous
почему сломает? Просто не будет комплироваться старыми компиляторами. А проверять ошибки, как и раньше, никто запретить не может
потому что есть переменные с такими названиями, а именами переменных не могут быть ключевые слова
aadz
С чек/хендл хендл может быть только проблема у тех буратин, кто ошибку возвращал не последним значением
Wingman
С чек/хендл хендл может быть только проблема у тех буратин, кто ошибку возвращал не последним значением
Нет, причем тут вообще ошибка
Wingman
Я могу запросто переменную/функцию сейчас и чек, и хендл назвать
Wingman
И оно сломается
Semyon
я вот конечно не эксперт но в целом имутабельность очень мощная вещь, но выглядит уж очень накрученно по синтаксису
Roman
я вот все же думаю, что начинать надо с комментов-аннотаций, и линтера
да, в этом есть смысл. Можно с этого начать, правда я Go линтеры ещё не писал, сложно оценить насколько это будет сложно и затратно по времени.
можно добавить эту идею в пропосал как PoC implementation, осталось только придумать стандарт/формат аннотаций, есть по этому поводу идеи?
Daniel
есть
Daniel
к переменным и типам - теги