загляни в create он вызывает openfile
func Create(name string) (*File, error) {
return OpenFile(name, O_RDWR|O_CREATE|O_TRUNC, 0666)
}
Я в курсе. Вопрос в том, что для одного случая есть сахар, для другого - нет.
Anonymous
nikita
его метод Exists тоже будет вызывать`Open`
nikita
просто единственный common кейс, когда тебе надо проверить, есть ли файл, когда ты проверяешь сразу много файлов. а тогда ты просто вычитываешь навания файлов в директории и смотришь на слайс
nikita
разве нет?
Alexey 〒.
Я в курсе. Вопрос в том, что для одного случая есть сахар, для другого - нет.
в случае создания не нужно париться на счет прав и флагов.
А вот проверка выполняется и без сахары просто
Anonymous
Короче вот тут мнение разраба
https://stackoverflow.com/questions/12518876/how-to-check-if-a-file-exists-in-go
[...] It's not actually needed very often and [...] using os.Stat is easy enough for the cases where it is required.
Anonymous
Тогда остаётся вопрос, почему нету функции простого копирования файлов.
nikita
ну он как раз пишет, что это никто не использует
nikita
Тогда остаётся вопрос, почему нету функции простого копирования файлов.
скорее всего потому, что копирование из, например, http.Body файл и копирование из файла в файл сейчас одинаковые, Reader Writer все дела
и опять же, усложнять незачем . ридер у тебя всегда есть, если ты открыл файл
Michael
Короче вот тут мнение разраба
https://stackoverflow.com/questions/12518876/how-to-check-if-a-file-exists-in-go
[...] It's not actually needed very often and [...] using os.Stat is easy enough for the cases where it is required.
так себе отговорка
а потом почти у каждого вариации на тему
func IsExists(path string) bool {
if _, err := os.Stat(path); os.IsNotExist(err) {
return false
}
return true
}
nikita
nikita
даже ой
Michael
скорее всего потому, что копирование из, например, http.Body файл и копирование из файла в файл сейчас одинаковые, Reader Writer все дела
и опять же, усложнять незачем . ридер у тебя всегда есть, если ты открыл файл
там если интерфейс поддерживаются, то ок. так же удобно сделали что из нескольких ридеров в один врайтер можно данные копировать
Michael
но с ос статс как-то через чур
Anonymous
скорее всего потому, что копирование из, например, http.Body файл и копирование из файла в файл сейчас одинаковые, Reader Writer все дела
и опять же, усложнять незачем . ридер у тебя всегда есть, если ты открыл файл
А если файлы надо просто копировать/перемещать без открытия?
Alexey 〒.
А если файлы надо просто копировать/перемещать без открытия?
ну ты же понимаешь что открытие все равно будет?
Michael
юзай команды bash
Michael
там и го не нужен для просто скопировать
nikita
А если файлы надо просто копировать/перемещать без открытия?
расскажи про копирование без открытия
Alexey 〒.
из го вызывать команды bash)
Anonymous
для перемещения есть os.Rename
Не работает, если нужно переместить между разными носителями (например, из tmpfs на диск).
Aleksandr
ребят, а вы еще продолжаете?))) третий час подходит к концу
nikita
скучно (
Anonymous
а реализацию то)
Ты наверно не понял, про что ведём разговор. Вопрос в том, почему на такой простой функционал каждый прогер должен писать свою реализацию вместо того, чтобы вызвать свою функцию из стандартной либы.
Dmitry
ребят, а вы еще продолжаете?))) третий час подходит к концу
намекает что за это время можно было бы и библиотеку написать 😉
nikita
Ты наверно не понял, про что ведём разговор. Вопрос в том, почему на такой простой функционал каждый прогер должен писать свою реализацию вместо того, чтобы вызвать свою функцию из стандартной либы.
я же говорю, из-за интерфейсов Reader и Writer
они обобщают работу надо всем, не только над файлами. и существубщая функция для всего подходит
Anonymous
Вот по поводу перемещения https://github.com/golang/go/issues/13766
Anonymous
я же говорю, из-за интерфейсов Reader и Writer
они обобщают работу надо всем, не только над файлами. и существубщая функция для всего подходит
На что я парирую, что os.OpenFile тоже годится и для создания файла, и для открытия. Но для них написаны os.Create и os.Open соответственно.
Anonymous
Ладно, я что-то устал ))
nikita
На что я парирую, что os.OpenFile тоже годится и для создания файла, и для открытия. Но для них написаны os.Create и os.Open соответственно.
на что я сошлюсь на ответ контрибьютера про частоту использования
nikita
да
nikita
на что я сошлюсь на ответ контрибьютера про частоту использования
который довольно очевиден хз
Michael
на частоту сферических коней в ваккууме
Anonymous
на что я сошлюсь на ответ контрибьютера про частоту использования
Наверно исследование они провели ))
Michael
в баре с шмузи
nikita
Наверно исследование они провели ))
чтобы узнать, что в детроите воняет, не надо туда ездить)
Michael
провели точно хорошо время
Alexey 〒.
Alexey 〒.
в случае создания не нужно париться на счет прав и флагов.
А вот проверка выполняется и без сахары просто
Anonymous
в случае создания не нужно париться на счет прав и флагов.
А вот проверка выполняется и без сахары просто
> в случае создания не нужно париться
В винде да. В линуксе не соглашусь.
Alexey 〒.
> в случае создания не нужно париться
В винде да. В линуксе не соглашусь.
С чем не согласишься? Cо своим доводом? Create дефолтный только есть, с параметрами по умолчанию
Нужен наверно еще такой?)
func Create(name string, flag int, perm FileMode) (*File, error) {
return OpenFile(name, flag, perm)
}
Michael
а что с виндой не так?
Michael
ругнуться на отсутствие прав и она может
Michael
ой, всё! (с)
Zloy-Dobry
ага да
Axm
делаю простой DI типа того, как описано в этой статье https://appliedgo.net/di/. если у меня все в разных пакетах, то куда будет по фень-шую засунуть интерфейс? т.е. пакет А с методом М1 требует интерфейс И1. структура с методом, который его реализует, находится в пакете Б. интерфейс надо куда класть? в А, Б или третий пакет?
Aleksandr
поясни, не хочу додумывать, что ты имел в виду
Aleksandr
что значит "пакет требует", кого реализовывает?
Viktor
Axm
поясни, не хочу додумывать, что ты имел в виду
там по ссылке есть пример кода в конце. представь, что Poem, Notebook и Napkin в разных пакетах. куда положить интерфейс, который все это связывает между собой?
Anonymous
субъективный вопрос
Axm
ну вот мне интересно, кто как думает
Anonymous
если все остальное в разных пакетах - то в отдельный пакет, если они все в одном пакете - то в тот же пакет
Aleksandr
смотри. ты можешь воспользоваться интерфейсом стороннего пакета (пусть и своего), можешь абстрагироваться своим интерфейсом. все зависит от того, насколько ты хочешь сделать несвязанный пакет
Aleksandr
хочешь узнать кто как бы сделал, озвучь конкретный кейс
Axm
да я сразу понял, что можно куда угодно, вопрос куда правильнее?
Aleksandr
> представь, что Poem, Notebook и Napkin в разных пакетах
это не имеет смысла
Anonymous
я бы положил все это в 1 пакет
Axm
чо это? а если у меня много кода и клиенты к разным системам?
Axm
есть несколько клиентов к разным третьим системам. в одном клиенте надо вызывать другой по ходу работы. в другом тоже так.
Илья
Axm
а как надо?
Axm
скажите еще, как отделить тест от пакета? чтобы переменные внутри тестов не были доступны пакету остальному. ну или как передать из TestMain нужные значения внутрь тестовых методов, не делая их глобальными?
Stepan
Aleksandr
есть несколько клиентов к разным третьим системам. в одном клиенте надо вызывать другой по ходу работы. в другом тоже так.
еще разверни для понимания связанности пакетов
Aleksandr
что непонятно? я не знаю куда развернуть надо.
непонятна степень связанности пакетов. я же написал: правильное решение зависит от контекста. пакет зависит от другого пакета - это не контекст.
Aleksandr
по хорошему есть вот такая крайность - каждый пакет у тебя автономная единица, для каждой зависимости имеющая свой интерфейс. и пакеты между собой общаются через адаптеры. но зачастую это оверинжинирнг
Aleksandr
package A
type Client1 struct
type Client2 interface
type Client2BDecorator struct
package B
type Client2 struct
type Client1 interface
type Client1ADecorator struct
ceiling cat
Интересно
Aleksandr
декораторы реализуют интерфейсы своего пакета, декорируя клиентов из другого пакета
Axm
не, мне так сложно сейчас не надо, это будет слишком
Aleksandr
это в полной парадигме clean arch но этого слишком много для связанных систем
Axm
в данный момент у меня один пакет (клиент) вызывает по ходу работы метод другого пакета (клиента). то есть, запрашивает данные в другой системе.