Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета.
То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
Re: Теоретический вопрос по преимущесвту одной Java особенно
R>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета. R>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток? R>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
Допустим, программист вообще не вылезал из IDE. Он мог бы вообще не знать о существовании каких-то файлов, папок и путей.
В Java есть настоящие недостатки, а про структуру файлов это незначительная мелочь, которая расстраивает только первые два дня, где-то наравне с излишне мусорным синтаксисом.
Re[2]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Temoto, Вы писали:
R>>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета. R>>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток? R>>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
T>Это цвет сарая для велосипедов. T>http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality
T>Допустим, программист вообще не вылезал из IDE. Он мог бы вообще не знать о существовании каких-то файлов, папок и путей. T>В Java есть настоящие недостатки, а про структуру файлов это незначительная мелочь, которая расстраивает только первые два дня, где-то наравне с излишне мусорным синтаксисом.
Полностью разделяю идею Паркинсона. Аналогия впрочем неуместна, поскольку вопрос не из области "что можно усовершенствовать в Яве" и даже не из области "недостатки Явы".
Меня интересует исключительно одна особенность.
Существуют люди, считающие применение вложенных папок удобством в Яве. Мне интересно, насколько распространено такое мнение.
Дело в том, что идея наложить ограничения на имена файлов и заставить пользователей вручную создавать сложные структуры папок, приходит некоторым в процессе разработки прикладных приложений, не относящихся средам программирования. В качестве аргумента в пользу сложного решения приводится пример Явы (мне все же кажется, что настоящий аргумент -- подкупающее упрощение реализации).
Вот я и спрашиваю, действительно ли много-папочность в Яве это ее преимущество (безотносительно к важности этого достоинства/недостатка в Яве).
Re[2]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Temoto, Вы писали:
R>>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета. R>>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток? R>>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
T>Это цвет сарая для велосипедов. T>http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality
T>Допустим, программист вообще не вылезал из IDE. Он мог бы вообще не знать о существовании каких-то файлов, папок и путей. T>В Java есть настоящие недостатки, а про структуру файлов это незначительная мелочь, которая расстраивает только первые два дня, где-то наравне с излишне мусорным синтаксисом.
Или вы какбэ намекаете, что если в предмете обсуждения разбирается больше одного человека, то следует принимать первое попавшееся может быть не самое дальновидное решение, чтобы не впадать в дискуссию о сарае? (Я говорю не о Яве, см. соседний пост)
Накопленная погрешность от таких решений может потом незаметно погубить проект, при этом каждое отдельное решение никем не воспринимается как причина провала.
Но я понял, понял, вы какбэ хотите сказать: важность вопроса ничтожна, поэтому лучше не тратить время на его обсуждение.
Интересно, как же определить, что следует обсуждать, а что нет?
Re[3]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Rothmans, Вы писали:
R>Вот я и спрашиваю, действительно ли много-папочность в Яве это ее преимущество (безотносительно к важности этого достоинства/недостатка в Яве).
Нет, это просто её особенность.
Как программист на Java, C++, C# и других языках, требования соответствия путей и пакета — это ТАКАЯ МЕЛОЧЬ по сравнению с остальным.
Sapienti sat!
Re: Теоретический вопрос по преимущесвту одной Java особенно
Здравствуйте, Rothmans, Вы писали:
R>Известно, что Ява предполагает, что исходный текст каждого класса должен находиться в отдельном файле в папке с путем соответствующим имени пакета.
Вообще-то нет.
R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
По мне — преимущество, т.к. делает проект более предсказуемым и менее зависимым от тараканов в голове у конкретных занимающихся им программистов.
Ку...
Re[2]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Пацак, Вы писали:
R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
П>По мне — преимущество, т.к. делает проект более предсказуемым и менее зависимым от тараканов в голове у конкретных занимающихся им программистов.
Спасибо, за ответ по теме
Re[4]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Cyberax, Вы писали:
C>Как программист на Java, C++, C# и других языках, требования соответствия путей и пакета — это ТАКАЯ МЕЛОЧЬ по сравнению с остальным.
Повторюсь: вопрос не о Яве и не о языках программирования. Вопрос, я бы сказал, об аргументации ява-подобного решения в прикладной программе.
Ответ, видимо, зависит от потребителя данного решения.
Для автоматической обработки проргаммой, мета-информацию до определенной степени, наверное, можно хранить в имени файла.
Требовать от пользователя ручного соблюдения сложных условий наименования, все же мне кажется недостатком для пользователя.
Re: Теоретический вопрос по преимущесвту одной Java особенно
Здравствуйте, Rothmans, Вы писали:
R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток? R>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
Ответ на первый вопрос: у Java нет такого требования. Своим classloader-ом можно грузить классы хоть из космоса.
Ответ на второй вопрос: может быть и да, поскольку бардак на столе или в комнате иногда позволяет быстро находить какую-нибудь часто используемую вещь, лежащую на самом видном месте.
bloß it hudla
Re[2]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Rothmans, Вы писали:
R>>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток? R>>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
AL>Ответ на первый вопрос: у Java нет такого требования. Своим classloader-ом можно грузить классы хоть из космоса.
А как вы практически создаете класс, для загрузки "из космоса"? Структуру каталогов не соблюдаете?
(Мне знаком принцип отделения средства хранения исходных текстов от стандарта языка, но мы же все хорошо понимаем, о чем идет речь)
AL>Ответ на второй вопрос: может быть и да, поскольку бардак на столе или в комнате иногда позволяет быстро находить какую-нибудь часто используемую вещь, лежащую на самом видном месте.
А если в понедельник удобно находить мусор на столе по имени пакета, а в среду по зависимосям между ними, а в пятницу по версии или размеру.
Вы собираетесь все эти свойства запихивать в имена каталогов и файлов ваших исходных файлов?
Вы считаете манифесты неудобством, потому что их содержимое не является частью имени файла?
Re[3]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Rothmans, Вы писали:
R>А как вы практически создаете класс, для загрузки "из космоса"? Структуру каталогов не соблюдаете? R>(Мне знаком принцип отделения средства хранения исходных текстов от стандарта языка, но мы же все хорошо понимаем, о чем идет речь)
Соблюдаю структуру пакетов, которая естественным образом отображается на иерархию путей в пределах локальной/удаленной файловой системы, в пределах одного или нескольких jar-ов и т.д.
R>А если в понедельник удобно находить мусор на столе по имени пакета, а в среду по зависимосям между ними, а в пятницу по версии или размеру. R>Вы собираетесь все эти свойства запихивать в имена каталогов и файлов ваших исходных файлов?
Нет, не собираюсь. Поскольку в Java-проектах до 500 KSLOC пока не имел таких проблем. А вот в небольшой build-системе, написанной в виде AddIn-а к MSVS на C#, при переходе от одной версии студии к другой -- да, замахался правильные версии сборок подставлять.
R>Вы считаете манифесты неудобством, потому что их содержимое не является частью имени файла?
Нет, не считаю, тем более что манифест был в jar-ах, когда .NET еще пешком под стол не ходил. Но считаю абсурдом иметь в C#-проекте отдельную роль "специалист по сборкам", каковую довелось видеть в соседнем подразделении.
bloß it hudla
Re: Теоретический вопрос по преимущесвту одной Java особенно
Здравствуйте, Rothmans, Вы писали:
R>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
Вот именно. Для других языков это требование попросту отсутствует, кладите свой EXE куда хотите, он один. А для Java, коль скоро необходимо это требование выполнять, то и для исходников логично то же требование.
With best regards
Pavel Dvorkin
Re[4]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, A.Lokotkov, Вы писали:
R>>Вы считаете манифесты неудобством, потому что их содержимое не является частью имени файла?
AL>Нет, не считаю, тем более что манифест был в jar-ах, когда .NET еще пешком под стол не ходил. Но считаю абсурдом иметь в C#-проекте отдельную роль "специалист по сборкам", каковую довелось видеть в соседнем подразделении.
Вообще-то я не собирался сравнивать Яву с С#
Но мимо последнего ваше замечания насчет ненужности "специалиста по сборкам" не смог пройти мимо
Это вы видимо в больших и многогранных проектах не участвовали и не знакомы с принципами менеджмента конфигураций.
Когда у вас 20+ проектов, использующих 3-5 разных базовых технологий. И надо придерживаться ISO и местных Agile правил. И все вместе надо минимум 2 раза в неделю собирать и чтобы любой билд был зафиксирован в Agile и его можно было зарепродьюсить. И при этом разработчики сидят в часовых поясах с раностью в 9 часов
Я слабо представляю, как в такой ситуации можно обойтись без "специалиста по сборкам".
Re[2]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Rothmans, Вы писали:
R>>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
PD>Вот именно. Для других языков это требование попросту отсутствует, кладите свой EXE куда хотите, он один. А для Java, коль скоро необходимо это требование выполнять, то и для исходников логично то же требование.
Согласен, логично. Не неудобно же, по сравнению с другими средами, которые позволяют класть что угодно куда угодно при желании.
На самом деле, на мой взгляд, самый большой недостаток малозначительной много-папочности в Яве это те миллионы кликов по папкам которые так или иначе (не все же вы буквально в жизни делаете в IDE) тратятся человечеством при разработке на Ява. С мира по нитке -- нищему сорочка (утечка производительности).
Но этот вопрос, я согласен, из разряда покраски сарая.
Обоснование применения того же принципа в коммерческом прикладном продукте примером Явы -- уже не такой уж и вопрос о сарае.
Re: Теоретический вопрос по преимущесвту одной Java особенно
А вот мне кстати вспомнился вполне осязаемый недостаток много-папочности.
Все время приходится на Виндоуз следить, чтобы реультирующее имя файла случайно не превысило 250 символов, потому как некоторые не связанные с Явой вещи (копирование в опред. обстоятельствах например) начинают глючить (как минимум на Виндоуз 2003 Сервер это еще так).
Вы скажете, что это недостаток Виндоуз. А я скажу, что Виндоуз требует кастомер, и он не собирается переходить на что-либо другое из-за длинных имен файлов, которых он и не заказывал.
Re[3]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Rothmans, Вы писали:
PD>>Вот именно. Для других языков это требование попросту отсутствует, кладите свой EXE куда хотите, он один. А для Java, коль скоро необходимо это требование выполнять, то и для исходников логично то же требование.
R>Согласен, логично. Не неудобно же, по сравнению с другими средами, которые позволяют класть что угодно куда угодно при желании.
Когда это "что угодно" есть 1 файл, то можно его и класть куда угодно. Когда же файлов сотни и тысячи, то без какой-то архитектуры не обойтись. Придумывать еще одну — вряд ли имеет смысл.
Ну а что касается того, что в Яве каждый файл компилируется в свой файл .class и они все вместе поставляются (jar ничего не меняет), то это другой вопрос.
With best regards
Pavel Dvorkin
Re[5]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Rothmans, Вы писали:
R>Вообще-то я не собирался сравнивать Яву с С#
Я и не утверждал, что Вы собираетесь сравнивать или сравниваете. И сам тоже не сравниванию, кстати. Там, просто-напросто, был симметричный ответ на Ваши домыслы по поводу того, что я, якобы, считаю манифест неудобством.
R>Но мимо последнего ваше замечания насчет ненужности "специалиста по сборкам" не смог пройти мимо R>Это вы видимо в больших и многогранных проектах не участвовали и не знакомы с принципами менеджмента конфигураций. R>Когда у вас 20+ проектов, использующих 3-5 разных базовых технологий. И надо придерживаться ISO и местных Agile правил. И все вместе надо минимум 2 раза в неделю собирать и чтобы любой билд был зафиксирован в Agile и его можно было зарепродьюсить. И при этом разработчики сидят в часовых поясах с раностью в 9 часов R>Я слабо представляю, как в такой ситуации можно обойтись без "специалиста по сборкам".
О да, конечно же нигде не участвовал и ни с чем не знаком . Поэтому мне будет простительно не понимать, как соотнести отдельного специалиста по дотнетным сборкам со всеми этими страшно крутыми словами: Agile, ISO, 20+/3-5 базовых технологий.
Всего доброго.
bloß it hudla
Re[6]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Rothmans, Вы писали:
R>>Вообще-то я не собирался сравнивать Яву с С#
AL>Я и не утверждал, что Вы собираетесь сравнивать или сравниваете. И сам тоже не сравниванию, кстати. Там, просто-напросто, был симметричный ответ на Ваши домыслы по поводу того, что я, якобы, считаю манифест неудобством.
Прошу прощения, если мой вопрос показался Вам домыслом.
R>>Но мимо последнего ваше замечания насчет ненужности "специалиста по сборкам" не смог пройти мимо R>>Это вы видимо в больших и многогранных проектах не участвовали и не знакомы с принципами менеджмента конфигураций. R>>Когда у вас 20+ проектов, использующих 3-5 разных базовых технологий. И надо придерживаться ISO и местных Agile правил. И все вместе надо минимум 2 раза в неделю собирать и чтобы любой билд был зафиксирован в Agile и его можно было зарепродьюсить. И при этом разработчики сидят в часовых поясах с раностью в 9 часов R>>Я слабо представляю, как в такой ситуации можно обойтись без "специалиста по сборкам".
AL>О да, конечно же нигде не участвовал и ни с чем не знаком . Поэтому мне будет простительно не понимать, как соотнести отдельного специалиста по дотнетным сборкам со всеми этими страшно крутыми словами: Agile, ISO, 20+/3-5 базовых технологий.
AL>Всего доброго.
Ну ну, не расстраивайтесь, я не хотел Вас обидеть, специально заменял крутые слова безграмотным сленгом
Re[7]: Теоретический вопрос по преимущесвту одной Java особе
Здравствуйте, Rothmans, Вы писали:
R>То же самое должно соблюдаться для расположения скомпилированных класс-файлов.
На расположение бинарей наплевать.
R>Как вы считаете, требование на расположение файлов в строго определенном месте зачастую в многоуровневой вложенной структуре каталогов, это преимущество или недостаток?
По мне так это крайне неудобно. Как и правило один класс — один файл.
R>Было бы удобнее работать, если бы Ява не накладывала таких условий, как например C#?
Да!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока