Здравствуйте, Xentrax, Вы писали:
X>Ну вот я же и расписал сразу после этой строчки. Конкретный пример: вот у нас есть штук 10 больших файлов по 5000 строк, их постоянно кто-то правит, и все записываются в очередь на чек-ин. Кто-нибудь забывает положить в америке или в японии, мы тогда здесь в москве этот файл додумываем, чтобы компилировалось, и потом люди его забирают через шару.
На вопрос ты не ответил. Все же как размер команды влияет на размер исходников?
5000 строк это где-то 300 кил исхоников. Я вот сейчас глянул ни в одном проекте из доступных мне сейчас таких огромных файлов созданных вручную нет. Есть правда около того, но они все автосгенерированны.
X>Тот же пример с парсерами тут где-то в ветке был. Пока один человек пишет, все нормально, а ну как проект вырастет, наймут еще пару атусорсеров? Фигня получится.
Не нужно мне про парсеры расскзаывать. Я как бы их тоже делал. Нармальный подход тут использование генератора кода. С ним и размеры приемлемые остаются. И разобраться в коде проще. Ну, а самый объемный код (аст и его обработка) прекрасно распихиваются по отдельным файлам.
Так что тут дело рне в размере команды, а в ее качестве.
X>Поэтому серьезный многолетний проект должен состоять из маленьких файлов.
Почему-то мне кажется, что любой проект должен состоять из как можно более маленьких (ну, не до маразма конечно) файлов. И совершенно не важно что за команда. 5000 строк, кстати, перебор для любого проекта. Та же граматика C# из R#-а, со всеми обработками занимает ~3500 строк. А ведь больше будет только в С++.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Короткие или длинные исходинки - Модульный подход
Здравствуйте, stalcer, Вы писали: S>А насчет выгрузки. Я нигде не видел такой реализации, ни в Java ни в .Net.
Ну щас прям. В Java классы собираются GC точно так же, как и объекты. В .Net единицей деплоймента является сборка, но вплоть до 2.0 можно выгрузить только домен целиком.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Павел Кузнецов, Вы писали: ПК>Имхо, большой интерфейс — в большинстве случаев следствие плохого дизайна.
Ну, вообще-то много места может отнимать банальный маппинг на всякие интерфейсы. Разработчики фреймворков страсть как любят декларировать всякие интерфейсы! А ты, если хочешь быть с ними соупотребляем, будешь их реализовывать. Вон, в DevExpress типичный контрол штук десять-пятнадцать интерфейсов реализует. Причем большинство из них — тривиально. Вот как раз эту часть имеет смысл выкинуть в отдельные файлы, т.к. никакой особо осмысленной логики там нет.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, FDSC, Вы писали:
FDS>Между прочим, при анализе исходников, в "серьёзных классах" ориентироватся гораздо легче, т.к. при разбиении последних обычно получается запутанная иерархическая структура — ад для отладки и производительность обычно ниже.
Снова напоминаю о необходимости бросать плохие среды. Нормальная среда разработки содержит полноценный отладчик, которому поровну количество классов, и полноценный компилятор, который оптимизирует все опять же независимо от количества классов.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Xentrax, Вы писали: X>А уж для языка С++ это категорически так. X>Причем должна быть известна функция ИмяФайла=F(ИмяТипа).
Кстати, важное замечание. Я тоже про это подумал. Хорошо, когда у тебя проект в почти готовом виде, и go to definition работает. А иначе все — труба, запаришься ты разыскивать этот класс.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Короткие или длинные исходинки - Модульный подход
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Xentrax, Вы писали: X>>А уж для языка С++ это категорически так. X>>Причем должна быть известна функция ИмяФайла=F(ИмяТипа). S>Кстати, важное замечание. Я тоже про это подумал. Хорошо, когда у тебя проект в почти готовом виде, и go to definition работает. А иначе все — труба, запаришься ты разыскивать этот класс.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>В .Net единицей деплоймента является сборка, но вплоть до 2.0 можно выгрузить только домен целиком.
V>А в 2.0?
В 2.0 вроде можно на лету компилировать специальные делегаты, которые собираются GC без явной выгрузки домена.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Здравствуйте, Sinclair, Вы писали:
S>>>В .Net единицей деплоймента является сборка, но вплоть до 2.0 можно выгрузить только домен целиком.
V>>А в 2.0? S>В 2.0 вроде можно на лету компилировать специальные делегаты, которые собираются GC без явной выгрузки домена.
Странно
Делегат — это экземпляр полноценного типа (после его автоматического создания). Т.е. GC сможет выгружать типы? Скажем, не имеющие статиков?
Re[17]: Короткие или длинные исходинки - Модульный подход
Здравствуйте, vdimas, Вы писали:
V>Странно
Угу. V>Делегат — это экземпляр полноценного типа (после его автоматического создания). Т.е. GC сможет выгружать типы? Скажем, не имеющие статиков?
Не могу сейчас найти; это было в блоге одного из разработчиков по поводу улучшений в новом Reflection.Emit.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Короткие или длинные исходинки - Модульный подход
Здравствуйте, Sinclair, Вы писали:
S>Ну щас прям. В Java классы собираются GC точно так же, как и объекты. В .Net единицей деплоймента является сборка, но вплоть до 2.0 можно выгрузить только домен целиком.
Начиная с Java 1.2 классы можно выгрузить только вместе с ClassLoader-ом. То есть по сути ClassLoader получается аналогом домена в данной ситуации.
.
