Здравствуйте, L_G, Вы писали:
BFE>>Это ошибочный подход из-за "многопоточности". Файл в любой момент может быть удалён кем-то ещё, поэтому проверка что-либо до вызова функции не гарантирует, что в момент вызова функции файл всё ещё будет существовать. L_G>"Ошибочность" вряд ли есть в предварительной проверке того, существовал ли файл вообще (или его "забыли" создать, или записали в другую папку и т.п. — т.е. в проверке на ошибки пользователя/интеграции/конфигурации/забывчивого программиста).
Я имел ввиду TOC/TOU
BFE>>Ага, я такую "экономию" не один год уже наблюдаю: коллектив переписывает одну и ту же функциональность в который раз. И каждый раз с ошибками отличными от предыдущей реализации. На каждом конкретном месяце экономия есть, а в целом — упущенная выгода. Впрочем это проблемы работодателя, а не работников.
L_G>Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).
Вряд ли. Скорее методология должна соответствовать задаче. YAGNI не годится для V-Model, но подходит для agile. При этом сам agile не подходит для тех задач, где чёткие требования прописанные и подписанные в договоре, где V-Model — самое то.
L_G>BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.
Не, большинство выбирает ехать, а не шашечки и как следствие частые аварии ведущие к костылям.
Здравствуйте, kov_serg, Вы писали:
BFE>>Нет, просто файлы разные. _>Вы уже определитесь. Разные это значит только разное содержимое, любые метаданные туда не входят ни права ни атрибуты ни владелец ни дата на расположение на диске и т.п.
Да, с этим, пожалуй, стоит определиться...
Если положить, что файлы считаются одинаковыми если приложение может сравнить содержимое (без запуска внешних приложений) и это содержимое одинаково, то будут какие-то дополнительные проблемы?
Здравствуйте, B0FEE664, Вы писали:
BFE>Да, с этим, пожалуй, стоит определиться... BFE>Если положить, что файлы считаются одинаковыми если приложение может сравнить содержимое (без запуска внешних приложений) и это содержимое одинаково, то будут какие-то дополнительные проблемы?
"если приложение может сравнить содержимое" а если не может — отсутствие результата тоже результат
L_G>>Всегда остаётся вероятность, что YAGNI придумали идиоты и применение этого принципа в массовом индустриальном/энтерпрайзном программировании неоправдано. Но я в этот принцип почему-то поверил и даже широко применяю (видимо, потому, что я очень ленивый программист).
BFE>Вряд ли. Скорее методология должна соответствовать задаче. YAGNI не годится для V-Model, но подходит для agile. При этом сам agile не подходит для тех задач, где чёткие требования прописанные и подписанные в договоре, где V-Model — самое то.
YAGNI — обычно про фазу ПРОЕКТИРОВАНИЯ РЕАЛИЗАЦИИ требований/задачи. (Иногда её выполнят тот же программист, что и кодирует, но не суть.) И тогда ЕСЛИ у проектировщика/программиста возникает вопрос "а не забубенить ли мне/нам в коде ЕЩЕ И ЭТО?", YAGNI дает ответ: "НЕТ, это тебе/нам ПОКА не нужно. Когда будет нужно — поймём и тогда уже забубеним (когда уже нельзя будет отвертеться)."
В V-Model, насколько понимаю, есть выделенная стадия проектирования, которая должна завершиться до начала кодирования, но не суть. ЕСЛИ у проектировщика возник вопрос "а не забубенить ли нам...?" (при неизменности спущенных ему сверху требований), то он вполне может применить YAGNI и решить НЕ забубенивать, поскольку внешние требования этого не требуют и у него ЕСТЬ ВЫБОР. Кстати, экономия времени — это экономия денег (или становится ей при возрастании масштаба). Думаю, YAGNI подтверждает свою полезность статистически (на большинстве случаев), хотя всегда есть шанс не угадать (отказаться от того, что в будущем окажется полезным) и проиграть.
Даже на этапе обсуждения ТЗ с заказчиком YAGNI вполне применимо! Тут уже речь об экономии денег/времени заказчика. Если исполнитель хочет загрузить себя работой по максимуму, ОН применять YAGNI, урезая себе ТЗ и общую сумму договора, конечно же, не станет. Хотя — стоп — он ведь может надеяться на то, что урезанный проект обязательно потребует доработок и общая сумма с доработками будет больше, чем если всё сделать сразу. Тогда опять же использование YAGNI приобретает глубокий смысл
L_G>>BTW, рационально мыслящие программисты обычно практикуют не переписывание с нуля, а дописывание нового с одновременным рефакторингом старого (рефакторинга в рамках необходимого для того, чтобы новое вписалось органично, а не в виде костылей). Думается, тем коллективом двигало как раз то самое хорошо знакомое тебе стремление сделать программирование интересным.
BFE>Не, большинство выбирает ехать, а не шашечки и как следствие частые аварии ведущие к костылям.
Тут я рассуждаю о конкретном случае "коллектив переписывает одну и ту же функциональность в который раз."
Если "выбирает ехать, а не шашечки" — о том, что впендюривают костыли, не тратя время на рефакторинг — то это случай, прямо ПРОТИВОПОЛОЖНЫЙ описанному переписыванию с нуля.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Почему меня не покидает ощущение, что Вы вдумчиво подсчитываете чертей/ангелов на кончике иглы?
Это потому, что они тоже не существуют.
Легко работать с объектами, которые существуют, а вы попробуйте сравнить два несуществующих файла. Не так-то это просто!
Как я понял из ответов есть разные подходы:
1) вообще не решать задачу в её рамках;
2) ввести аксиому, что отсутствующий файл равен пустому, тогда два несуществующих файла, очевидно, равны;
3) сказать, что генератор случайных чисел — это тоже файл и через это безумие сделать постановку задачи бессмысленной (ибо файл перестаёт быть равен самому себе);
4) сказать, что файл вне системы рассматривать смысла нет, поэтому надо использовать какие-то внутренние системные свойства...
Вывод: вопрос сложный, а значит поступать можно произвольно.
Написал функцию так, чтобы результат был false для случая когда один или оба файла не существуют. (Несуществующий файл не равен самому себе). Практика покажет, будут ли с этим проблемы.
PS Кстати, аналогия с указателями не верна: нулевой указатель и указатель на несуществующий объект — это два разных указателя.
Здравствуйте, B0FEE664, Вы писали:
BFE>вы попробуйте сравнить два несуществующих файла.
Вот совершенно не вижу ни малейшей надобности. Сколько себя помню, ни разу не требовалась функция, успешно завершающаяся при любой (из четырех возможных) конфигурации двух файлов, и возвращающая только true/false. В программах, которые доводилось разбирать, тоже никогда такого не видел.
BFE>1) вообще не решать задачу в её рамках;
Каким образом была поставлена такая задача? Уж не "а давайте придумаем вот такое"?
BFE>Вывод: вопрос сложный
На мой взгляд, вопрос тупо бессмысленный.
BFE>Написал функцию так, чтобы результат был false для случая когда один или оба файла не существуют.
Что на очереди? Функция сравнения файла с указателем, возвращающая true, если файл не существует, а указатель равен нулю, и false в остальных случаях?
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>вы попробуйте сравнить два несуществующих файла. ЕМ>Вот совершенно не вижу ни малейшей надобности. Сколько себя помню, ни разу не требовалась функция, успешно завершающаяся при любой (из четырех возможных) конфигурации двух файлов, и возвращающая только true/false. В программах, которые доводилось разбирать, тоже никогда такого не видел.
А сколько раз вообще вам приходилось сравнивать два файла?
Здравствуйте, B0FEE664, Вы писали:
BFE>Это не настоящие файлы. Вот как сравнивать содержимое таких файлов? Так что их можно даже не рассматривать, тем более, что они редки о часто не поддерживаются файловой системой.
Я встречал реализацию в памяти, где имя файла существовало, но в реальности файла на дисках/внешних хранилищах физически не было. Поэтому легко было создавать файлы типа C:\xxx.log с разным содержимым. Если не сделать кэш по именам, то файлы будут разные, хоть и иметь одинаковые имена. Конструкция с оптимизацией, конечно, но удовлетворяет теперешним условиям. Причём не предполагалось, что файл изначально будут в памяти. Так что работа с ними была как с настоящими файлами, и в начале и была таковой.
Здравствуйте, B0FEE664, Вы писали:
BFE>А сколько раз вообще вам приходилось сравнивать два файла?
Сколько-то раз приходилось, не очень много. Это как-то должно влиять на мое мнение по этому вопросу?
Если должно, то мне очень много раз приходилось сравнивать между собой объекты в памяти, но ни разу не возникло мысли сделать универсальную (чтоб непременно возвращала только true/false и не бросала исключений) функцию, которая вместе с существующими объектами втихушку обрабатывала бы и несуществующие.
Здравствуйте, Vi2, Вы писали:
Vi2>Я встречал реализацию в памяти, где имя файла существовало, но в реальности файла на дисках/внешних хранилищах физически не было. Поэтому легко было создавать файлы типа C:\xxx.log с разным содержимым. Если не сделать кэш по именам, то файлы будут разные, хоть и иметь одинаковые имена.
И как там различались эти "разные" файлы с одинаковым именами? Если доступ к этим файлам происходил не по именам, а по каким-то другим реквизитам, то зачем таким файлам имена?
Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>А сколько раз вообще вам приходилось сравнивать два файла? ЕМ>Сколько-то раз приходилось, не очень много. Это как-то должно влиять на мое мнение по этому вопросу?
Да. На моё мнение. Прежде всего интересен опыт.
ЕМ>Если должно, то мне очень много раз приходилось сравнивать между собой объекты в памяти, но ни разу не возникло мысли сделать универсальную (чтоб непременно возвращала только true/false и не бросала исключений) функцию, которая вместе с существующими объектами втихушку обрабатывала бы и несуществующие.
Чтобы сравнивать работу с объектами в памяти с работой с файлами, нужно, чтобы объекты были доступны для любого приложения в системе и кто угодно мог бы их удалить в любой момент.
Говорят (сам не видел), что такое последний раз было в OS/2, и, как говорилось в рекламе, если в OS/2 у вас повиснет редактор текста, то у вас повиснет вся система, а если в Windows повиснет редактор текста, то повиснет только редактор, а не вся система.
Здравствуйте, B0FEE664, Вы писали:
BFE>Прежде всего интересен опыт.
Ну, мой личный, примерно 45-летний опыт программирования, на разных языках, в разных системах, ни разу не сталкивался с реализацией универсальной операции сравнения двух произвольных файлов, которая не обращала бы внимание на факт их существования, приравнивая несуществующий файл к пустому. По-моему, вполне очевидно, что подобная реализация была бы абсурдной даже в самых игрушечных API.
Если брать специализированные системы, то подобные реализации встречаются. Например, во многих прикладных программах можно встретить функции вроде "вернуть текст примечания к заказу". Если текст примечания хранится в отдельном файле, функция может возвращать пустой текст и для пустого, и для несуществующего файла. Соответственно будет работать и операция сравнения результата с пустым текстом.
ЕМ>>Если должно, то мне очень много раз приходилось сравнивать между собой объекты в памяти, но ни разу не возникло мысли сделать универсальную (чтоб непременно возвращала только true/false и не бросала исключений) функцию, которая вместе с существующими объектами втихушку обрабатывала бы и несуществующие.
BFE>Чтобы сравнивать работу с объектами в памяти с работой с файлами, нужно, чтобы объекты были доступны для любого приложения в системе и кто угодно мог бы их удалить в любой момент.
Такое бывает и с объектами в памяти при многопоточной работе. Но вряд ли встретите в мало-мальски серьезной программе универсальную функцию сравнения произвольных объектов, чтоб возвращала только true/false, невзирая на факт существования объекта. Предикаты вида IsEmpty/IsNotEmpty иногда для упрощения считают несуществующий объект (в том числе файл) пустым, но это сугубо частный случай.
BFE>как говорилось в рекламе, если в OS/2 у вас повиснет редактор текста, то у вас повиснет вся система, а если в Windows повиснет редактор текста, то повиснет только редактор, а не вся система.
Как-то очень странно. Насколько помню характеристики OS/2, она изначально делалась достаточно надежной, и такое влияние рядового приложения на работу системы крайне маловероятно. А вот в 16-разрядных Windowss такое как раз бывало, если приложение слишком хитрожопое.
Здравствуйте, B0FEE664, Вы писали:
BFE>Не согласен. NULL строка — это такая строка, у которой нет значения. Например это строковое поле в базе данных у которого нет никакого значения.
Противоречите сами себе. У NULL строки значения нет. Его семантика — "мы не знаем". У "" значение есть — это пустая строка.
По канону, Len(NULL) даёт NULL — раз мы ничего не знаем о строке, то и длины её мы не знаем.
Len("") даёт 0. IndexOf(NULL, "мама мыла раму") даёт NULL, т.к. на вопрос "где в заданной строке находится неизвестно что" правильным ответом является "мы не знаем".
IndexOf("", "мама мыла раму") даёт 0, т.к. пустая подстрока "встречается" в любой строке везде, и самое первое вхождение — перед первым символом.
Соответственно, "" = "" даёт TRUE, "" = NULL даёт UNKNOWN, и NULL = NULL тоже даёт UNKNOWN.
То, что в Оракле сделано не так — это личные гуси Тома Кайта.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
