блокчейн это распределенное хранилище

распределенное - это когда чать инфы на одной ноде, часть на другой те блокчейны, что я знаю - не распределенные, а реплицированные: на каждой ноде вся инфа

ну вопрос терминологии

я понимаю

я не понимаю, зачем нужна вводящая в заблуждение терминология

мэйби имеется в виду что хранилище организовано децентрализованно

нет мастера от которого реплики

то есть не в смысле архитекутры а в смысле безопасности тысызыть

привет а подскажите почему я не могу инициализировать мапу так? как это правильнее сделать? func main() { t := map[string]interface{} t["a"] = "23" fmt.Printf("%T - %v", t, t) }

те мне в мапе нужен объект любого типа string/int/bool

привет а подскажите почему я не могу инициализировать мапу так? как это правильнее сделать? func main() { t := map[string]interface{} t["a"] = "23" fmt.Printf("%T - %v", t, t) }

потому что надо добавить {}

привет а подскажите почему я не могу инициализировать мапу так? как это правильнее сделать? func main() { t := map[string]interface{} t["a"] = "23" fmt.Printf("%T - %v", t, t) }

t := map[string]interface{}{}

А make не круто?

ох е( спасибо!

А make не круто?

очень не круто.

очень не круто.

Расскажите?

привет а подскажите почему я не могу инициализировать мапу так? как это правильнее сделать? func main() { t := map[string]interface{} t["a"] = "23" fmt.Printf("%T - %v", t, t) }

Значение map объявляется как map[keyType]valueType{} В данном случае valueType = interface{}, поэтому правильно map[string]interface{}{}

Расскажите?

либа должна быть готова к импорту после go get. приложение должно быть готов к запуску после go get. если у вас есть Makefile - он или лишний, или ваш код требует чего-то кроме go get

либа должна быть готова к импорту после go get. приложение должно быть готов к запуску после go get. если у вас есть Makefile - он или лишний, или ваш код требует чего-то кроме go get

Та не, простите за скудность вопроса, но я про make(map[string]interface{})

я подозреваю, что надо бы что-то с этим сделать, но пока не придумал, что

Та не, простите за скудность вопроса, но я про make(map[string]interface{})

:)

я подозреваю, что надо бы что-то с этим сделать, но пока не придумал, что

Было бы очень неплохо чтобы в go get был бы аналог gomake

Или в build

ну вот пока не понятно

Или в build

Это бы сильно упростило бы запуск кодогенерации

погоди

кодогенерация - инструмент для создателя ПО, а не для пользователя

очень не круто.

Правда, почему make() - не круто?

Правда, почему make() - не круто?

мы уже разобрались, что я не на тот вопрос ответил

А, sorry

кодогенерация - инструмент для создателя ПО, а не для пользователя

Это не совсем так Есть кодогенерация, которую надо выполнять на этапе разработки пакета, например генерация protobuf или swag А в случае если она используется как замена дженериков, то она нужна на этапе разработки, и, имхо, должна запускаться автоматически ide или при сборке

go generate ./... чем тебе не угодил?

go generate ./... чем тебе не угодил?

Тем что это по сути тупой make? Это только для первого типа кодгена Второй должен работать на лету во время разработки

да вот непонятно про на лету

по какому событию оно должно на лету запускаться?

по какому событию оно должно на лету запускаться?

Либо при go build, либо, если есть умный редактор, когда нужно автодополнение и линтинг

а до go build твой код неполный, и синтаксическую проверку не пироходит, так, что ли?

И я думаю что кодогенераторы должны быть не в виде бинарников, а в виде функций Как test

эту мысль я не понял

если приложение собирается без генеренного кода - зачем он нужен такой

@onokonem а есть пример go generate для самых тупых похапешников?

а если не собирается - его надо раньше go build запускать

эту мысль я не понял

У тебя в проекте лежат функции вида func GenerateMyGenerator(*gen.Context) { ... }

@onokonem а есть пример go generate для самых тупых похапешников?

нет

Бля

как это нет?

grpc, swagger

как это нет?

эхехехехехе

У тебя в проекте лежат функции вида func GenerateMyGenerator(*gen.Context) { ... }

Которая выстреливает при go build

grpc, swagger

Надо поковырять

@madgopher запили сваггер под греймворк

У тебя в проекте лежат функции вида func GenerateMyGenerator(*gen.Context) { ... }

ну я обычно, когда пишу свой генератор, кладу его main.go где-то в проект, а в go:generate пишу go run path/main.go

У тебя в проекте лежат функции вида func GenerateMyGenerator(*gen.Context) { ... }

Которые вещаются как обработчики на конкретные типы например

как относитесь к 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 И которая запускается если только отслеживаемые места кода изменятся

ааа, вот чего ты хочешь! не забыть генерацию толкнуть! это да, это частая проблема

@madgopher запили сваггер под греймворк

Я уже реквестировал в одной либе поддержку грэйма

ааа, вот чего ты хочешь! не забыть генерацию толкнуть! это да, это частая проблема

В том числе Так автоматически получаем версионирование кодогенераторов, и они не в виде стремных бинарников, собираемых из vendor Так глядишь нормальная экосистема кодгена появится

и тут-то нам и нагенерят наши коллеги почитать всякого...

А генеренный код не надо читать

И править

как появится "нормальная экосистема" - так придется читать :(

А генеренный код не надо читать

Хммм

как появится "нормальная экосистема" - так придется читать :(

Ну если вы активно работаете с чужими кодогенераторами, то уже больно А так хоть какие то общие стандарты

Кстати это неплохой способ завести типы суммы, не меняя язык

как относитесь к 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 делам вобще плохо отношусь. И в данном случае - тоже

Кстати это неплохой способ завести типы суммы, не меняя язык

это как это?! я знаю один способ - на интерфейсах и тайпсвитче.

ERROR: S client not available

я к новым implicit делам вобще плохо отношусь. И в данном случае - тоже

но тогда ведь придётся писать: return const(newSlice) не слишком ли это overhead'но? Я предполагаю что implicitly кастить не-const в const - не опасно. Опасно кастить const в не-const imlicitly!

я бы даже сказал что кстатиь const в не-const должно быть невозможно и в таком случае implicit cast не-const в const будет, по моему, уместен

но тогда ведь придётся писать: return const(newSlice) не слишком ли это overhead'но? Я предполагаю что implicitly кастить не-const в const - не опасно. Опасно кастить const в не-const imlicitly!

А что делать с функциями, которые и вызывают только для того, чтобы получить от них объект для дальнейшей работы с ним?

А что делать с функциями, которые и вызывают только для того, чтобы получить от них объект для дальнейшей работы с ним?

можно плиз краткий пример? ? дабы не гадать что конкретно ты имеешь ввиду

А что делать с функциями, которые и вызывают только для того, чтобы получить от них объект для дальнейшей работы с ним?

не возвращать их них конст

Например, тупо, функция make([]interface{}) ?или типа того

я вот за эксплицитное всегда

я вот за эксплицитное всегда

+1

я вот за эксплицитное всегда

return const(immutable) хм? ?

я вот за эксплицитное всегда

почему? есть на то объективная причина?

Причина в том, чето если что-то делается, то не надо делать это по-тихому. Явное гораздо отчетливей, и часто лучше

почему? есть на то объективная причина?

хотя ты и не меня спросил :)

это как это?! я знаю один способ - на интерфейсах и тайпсвитче.

Вот это самое, но только под капотом Ведь, если сделать как я говорю, то нет разницы между линтером и кодогенератором Сначала он генерирует набор типов обёрток для интерфейса mySumType, а потом проверяет валидность использования: чтобы не вернуть nil вместо mySumType, в type switch должны быть проверены все варианты, либо есть default

И тд

Причина в том, чето если что-то делается, то не надо делать это по-тихому. Явное гораздо отчетливей, и часто лучше

ну хотя да... это предотвратит то, что мы можем случайно вернуть тот слайс как const, на который у нас есть mutable reference

Вот это самое, но только под капотом Ведь, если сделать как я говорю, то нет разницы между линтером и кодогенератором Сначала он генерирует набор типов обёрток для интерфейса mySumType, а потом проверяет валидность использования: чтобы не вернуть nil вместо mySumType, в type switch должны быть проверены все варианты, либо есть default

https://pastebin.com/AA33f6Xd

ну хотя да... это предотвратит то, что мы можем случайно вернуть тот слайс как const, на который у нас есть mutable reference

Пропозал твой прочитал. Добавить мне нечего, кроме уже скаанного. Хочу слово const, :)

В смысле, слово уже есть, но хочу больше const, короче :)

В смысле, слово уже есть, но хочу больше const, короче :)

не совсем понял

Ну, уже есть такое ключевое слово. Но хочу, чтобы оно больше было похоже на const из плюсов

Ну, уже есть такое ключевое слово. Но хочу, чтобы оно больше было похоже на const из плюсов

аналогично

я там кстати ещё вопрос по поводу констант vs имутабельных символов разобрал только-что: https://github.com/romshark/Go-2-Proposal---Immutability#35-how-are-constants-different-from-immutables

Кстати, кажется, что по логике Go должно быть не varName const []string), а наоборот - varName []string const) ?

я там кстати ещё вопрос по поводу констант vs имутабельных символов разобрал только-что: https://github.com/romshark/Go-2-Proposal---Immutability#35-how-are-constants-different-from-immutables

Блин, так бы хотелось, чтобы все было обругано на этапе компиляции, если надо, а не по ходу работы по разным памятям раскладывать потом и получать паники нафиг

Кстати, кажется, что по логике Go должно быть не varName const []string), а наоборот - varName []string const) ?

почему?

потому что паники

или ты тоже экстемист-параноик и все подрят тестируешь, как маньяк какой-то? :)

потому что паники

я про обратный порядок декларации, т.е. не const []string а []string const, зачем?

как в таком случае описать const [] const *Object ?

const [] const * const Object

Ехал констант через констант Видит констант в констант констант Сунул констант констант в констант Конст за констант констант цап