Комментарии 15
Пользуясь случаем спрошу как в Go обстоит дело с подключением одной и той же библиотеки, но разных версий? Например, есть два проекта, один проект нужно оставить со старой библиотекой, а другой обновить до последней версии. Как в Go разрешить эту проблему?
Разработчики языка на эту тему отписывались так:
либо идите в ногу со временем, либо делайте fork и мучайтесь со старой версией сами.
Лично я их мнение не разделяю :)
либо идите в ногу со временем, либо делайте fork и мучайтесь со старой версией сами.
Лично я их мнение не разделяю :)
А нельзя сделать так?
import newLib "lib/myLib" // newLib.func1()
import oldLib "lib/old_myLib" // oldLib.func1()Можно сделать по разному, вопрос о том как принято делать, чтобы каждый не городил велосипед. А еще желательно иметь официальную поддержку «как надо делать», прописанную в документации.
Можно конечно, это же пример с локальными библиотеками.
Проблема только с внешними библиотеками, у которых строка импорта == url адресу откуда пакет качается, поэтому нужно fork'ать и менять строку импорта, если хочешь определенную версию.
Проблема только с внешними библиотеками, у которых строка импорта == url адресу откуда пакет качается, поэтому нужно fork'ать и менять строку импорта, если хочешь определенную версию.
Я не утверждаю, что это что-то, что сложно сделать, каким-либо способом. Я хочу сказать, что на сегодняшний день нет общепринятого подхода для обработки этих моментов простым и последовательным образом.
Общепринятый подход сейчас, как я понимаю, такой: tour.golang.org/#65
+ исходящий канал сделать структурой с ошибкой и строчкой
Да, но данный подход не охватывает обработку ошибок.
Невнимательно прочитал, извиняюсь. Если исходящий канал делать структурой с ошибкой и строчкой, то получается что у нас возвращается всегда (n раз) структура в которой строчка и nil и 0 или 1 раз структура в которой nil и ошибка.
Подход из статьи хорош в случае, если ошибка — она один раз и все, завершение goroutine.
Ваш подход хорош в случае, если ошибка не приводит к завершению goroutine.
Подход из статьи хорош в случае, если ошибка — она один раз и все, завершение goroutine.
Ваш подход хорош в случае, если ошибка не приводит к завершению goroutine.
Интересная статья. Но сразу с погружением. Думаю, пригодилась бы статья про горутины, каналы (как средство взаимодействия между ними) и интерфейсы.
То есть те сущности языка, которые отличают Go от коллег по цеху.
Написал бы сам, но пока опыта в Go не хватает настолько, чтобы научить других.
PS: И спасибо за пост. Хаб обновляется почти раз в сутки, и нас тут уже 1000(!).
То есть те сущности языка, которые отличают Go от коллег по цеху.
Написал бы сам, но пока опыта в Go не хватает настолько, чтобы научить других.
PS: И спасибо за пост. Хаб обновляется почти раз в сутки, и нас тут уже 1000(!).
Да, и вот не совсем понятно: сам tomb где работает, в отдельной горутине? (не увидел создания) Если — да, то следит ли он за состоянием своей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Смерть goroutine под контролем