Здравствуйте, gandjustas, Вы писали:

H>>Чилды могут желать дернуть парента в момент своей смерти. На этапе проектирования я этот момент контролировать не могу т.к. чилды могут быть реализованы позднее и другим программистом, и ему может понадобиться дернуть парент перед смертью чилда. Я всячески пытаюсь избежать связанности реализаций, отсюда такое требование.

G>Ну приведи реальный пример задачи. Я больше чем уверен, что GC нормально ситуацию разрулит.
G>Сферический конь в вакууме не интересует

Я же тебе написал: на этапе проектирования я не могу контролировать этот момент. Это может потребоваться в будущем, и даже не мне. Что непонятного? Ты методы виртуальными делаешь для чего? Чтоб тут же их заюзать в потомки и все? Проектирвать на перспективу нужно. Это не сферическая задача, это часть моей текущей задачи, описывать которую ну ни какого смысла нет т.к. ключевой момент я уже выделил.

Здравствуйте, _d_m_, Вы писали:

H>>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.

___>Не понял разницы. ДотНет программы тоже не обязывают. А даже если бы обязывали: "также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры."

В смысле не обязывают? А эти конфиги упоминаемые тут для настройки ремотинга? Для пользователей любящих кофе давно есть клавы-"непромокайки" , и даже буки такие есть (видимо производитель счел, таки, недостатком )

Здравствуйте, _d_m_, Вы писали:

___>>>Это была шутка йумара. Здесь есть ярые поборники оного, впрочем, как и ты Дельфи.

H>>Я не поборник Delphi Я осведомлен о ее проблемах сильно больше, нежели нападающие тут. Я просто скромно, честь девушки отстаиваю

___>Она не девушка, так что смысл отстаивать? Да и по поводу чести девушки я тоже другого мнения что с ней делать (и девушки тоже, хотя обычно молчат). Отстаивать надо пену на пиве в кружках

Продукт хоть и носит имя города, но символом его (продукта) является Афина (которая девственница по мифологии), долгое время прусутствовавшая на сплешах

Здравствуйте, hattab, Вы писали:

H>Я же тебе написал: на этапе проектирования я не могу контролировать этот момент. Это может потребоваться в будущем, и даже не мне. Что непонятного? Ты методы виртуальными делаешь для чего? Чтоб тут же их заюзать в потомки и все? Проектирвать на перспективу нужно. Это не сферическая задача, это часть моей текущей задачи, описывать которую ну ни какого смысла нет т.к. ключевой момент я уже выделил.

Ты выделил не ключевой момент задачи, а ключевой момент её решения твоим способом.
Набор классов — не задача.
Опишешь задачу, больше чем уверен найдется адекватное решение на .NET.

ЗЫ С выделенным категорически не согласен.

Здравствуйте, gandjustas, Вы писали:

H>>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится.
G>Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально.

Улови разницу между "знаю, как сериализовать объект" и "знаю, как сериализуется объект".

G>В DCOM так не получится.

Немного больше работы ручками (создать библиотеки типов), только и всего. Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>>>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится.
G>>Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально.
H>Улови разницу между "знаю, как сериализовать объект" и "знаю, как сериализуется объект".
Пойми что в для передачи объектов по сети с помощью Remoting не нужно знать ни того, ни другого.

G>>В DCOM так не получится.
H>Немного больше работы ручками (создать библиотеки типов), только и всего.
Ну да, немного тут, немного там, а в итоге рукописного кода в разы меньше и ошибок соответственно в разы меньше.

H>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
Это очень важный момент при разработке в большой команде.

Здравствуйте, _d_m_, Вы писали:

___>>>FB это уже другая пестня, которая к Богланд уже не имеет никакого отношения.

H>>С Interbase'ом вообще мало работал, так, чисто для тестов. Но на Абрамсах он, тем не менее, стоял

___>Ну это не плюс Абрамсов, хотя пендосы так им гордятся. Один из лучших танков в мире, однако не лучший, но когда появится на них:
___>- автомат заряжания (у нас еще в на Т-64);
___>- стрельба как снарядами, так и ракетами на 5км по лазерному лучу из орудия причем зарядка ведется штатным автоматом заряжания (Т-64);
___>- аналог системы "Арена" (СССР 80 годы);
___>- приемлимый силуэт (Т-90 он явно сливает);
___>- приемлимый вес для езды по слабым грунтам и по большинству автомобильных мостов (Т-90 он сливает вчистую).

___>Вот тогда можно будет приводить в пример Абрамс. А так Абрамс для меня не авторитет.

___>PS: Смотрел передачу по National Geographic про Абрамс. Так вот там он позиционируется как единственный танк с ГТД. А про Т-80/Т-80У они типа не знали. Офтоп конечно, но по теме военной техники со мной лучше не спорить.

Я не говорю о плюсах Абрамса (а Oracle стоял на Тамагавках), я говорю, что этот факт хоть как-то, но характеризует Interbase

Вот еще:

Еще
один малоизвестный факт — использование InterBase для хранения
информации о кредитках в считывающих устройствах, которые используются
на немецких железных дорогах — одной из самых быстрых и развитых
транспортных систем в мире.

(c) Computerra.ru

Здравствуйте, gandjustas, Вы писали:

H>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
G>Это очень важный момент при разработке в большой команде.

Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно.

Здравствуйте, WolfHound, Вы писали:

WH>>>А зачем нам COM-интерфейсы?
H>>По условию задачи.
WH>Что это за условия такие?
WH>Кого вобще волнует какие там интерфейсы?
WH>Заказчика волнует только чтобы программа делала то что ему надо.

Со ссылками, вроде, разобрались. Но появился другой вопрос: как контролировать последовательность смерти интерфейсов, если она важна?

Здравствуйте, hattab, Вы писали:

H>Со ссылками, вроде, разобрались. Но появился другой вопрос: как контролировать последовательность смерти интерфейсов, если она важна?
А когда она важна?
От ответа на этот вопрос зависит ответ как контролировать.

Здравствуйте, gandjustas, Вы писали:

H>>Я же тебе написал: на этапе проектирования я не могу контролировать этот момент. Это может потребоваться в будущем, и даже не мне. Что непонятного? Ты методы виртуальными делаешь для чего? Чтоб тут же их заюзать в потомки и все? Проектирвать на перспективу нужно. Это не сферическая задача, это часть моей текущей задачи, описывать которую ну ни какого смысла нет т.к. ключевой момент я уже выделил.

G>Ты выделил не ключевой момент задачи, а ключевой момент её решения твоим способом.
G>Набор классов — не задача.

У меня не набор классов. У меня набор интерфейсов. Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят.

G>Опишешь задачу, больше чем уверен найдется адекватное решение на .NET.

Так я и так ее описал. Это не решение моим способом, как ты говоришь, это и есть задача. Я тебе могу описать ее в терминах предметной области, но что тебе это даст?

G>ЗЫ С выделенным категорически не согласен.

Да-да, ведь рефакторинг это круто

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, gandjustas, Вы писали:

H>>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
G>>Это очень важный момент при разработке в большой команде.

DOO>Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно.
А разве схема "один мегаархитектор и куча быдлокодеров" где-то работает?

Здравствуйте, gandjustas, Вы писали:

H>>>>В COM вообще нельзя ничего сложнее интерфейса да варианта передавать в метод . Я говорю о том, что если человек знает, как сериализовать объект, у него проблем с маршалингом оного не представится.
G>>>Пример, я не знаю как сериализуется объект. Я могу написать класс и пометить его атрибутом Serializable. И потом передавать по сети совершенно нормально.
H>>Улови разницу между "знаю, как сериализовать объект" и "знаю, как сериализуется объект".
G>Пойми что в для передачи объектов по сети с помощью Remoting не нужно знать ни того, ни другого.

Аналогично и в Delphi Можно делать ручками (о чем я и говорил), а можно пользоваться предоставляемым инструментом, который есть.

G>>>В DCOM так не получится.
H>>Немного больше работы ручками (создать библиотеки типов), только и всего.
G>Ну да, немного тут, немного там, а в итоге рукописного кода в разы меньше и ошибок соответственно в разы меньше.

Кто говорит о рукописном? Есть редактор библиотеки типов, который сам все напишет.

H>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
G>Это очень важный момент при разработке в большой команде.

При разработке в большой комаде, нужна идеология черного ящика для ядра системы, и такая его реализация, чтоб малограмотные не могли даже чихнуть без разрешения. Готовые универсальные решения, слабо подходят для такого типа разработки. В будущем обязательно вылезет какая нибудь проблема не укладывающаяся в "универсальные" рамки.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, gandjustas, Вы писали:

H>У меня не набор классов. У меня набор интерфейсов.
Перестань повторять эту тупость порожденную кривостью делфи. В любом случае это будут какие-то объекты.

H>Ключевое значение имеет обеспечение возможности чилдов иметь парента, когда они хотят.
А парент просто хранит ссылки на детей?

G>>Опишешь задачу, больше чем уверен найдется адекватное решение на .NET.
H>Так я и так ее описал. Это не решение моим способом, как ты говоришь, это и есть задача. Я тебе могу описать ее в терминах предметной области, но что тебе это даст?
Еще раз. Ты описываешь решение задачи, а ты опиши саму задачу. Забудь что у тебя есть компьютер, классы, интерфейсы. Просто скажи что должен увидеть пользователь.

G>>ЗЫ С выделенным категорически не согласен.
H>Да-да, ведь рефакторинг это круто
Не в рефакторигне дело.

Здравствуйте, hattab, Вы писали:

H>Кто говорит о рукописном? Есть редактор библиотеки типов, который сам все напишет.
С ужасно кривым интерфейсом редактирования. (Надеюсь с седьмой версии улучшили)

Здравствуйте, gandjustas, Вы писали:

H>>>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
G>>>Это очень важный момент при разработке в большой команде.

DOO>>Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно.
G>А разве схема "один мегаархитектор и куча быдлокодеров" где-то работает?

Ну вот. Ты сам понимаешь, что такое невозможно — так что придется кодеру вникать, никуда не денется.

Hi misha_irpen

ДГ>>>>Я даже больше скажу: в современной визуальной IDE под названием Eclipse формошлёпщик по умолчанию отсутствует.
_>>>Угу, вот потому его и используют одни "энтузиасты" и нищие фирмы-однодневки. А в корпоративном секторе (где существует такое понятие как срок сдачи проекта) юзают VS, который формошлепщиком оборудован по-умолчанию.
kuj>>Поржал. Пиши еще.
_>Если есть конкретные возражения -- в студию. Названия компаний, активно использующих этот ваш еклипс для чего-нибудь кроме джавы -- тоже.

Я давно не слежу за java. И еще больше за WebSphere. Но насколько мне известно то в WebSphere Studio (знающие люди поправьте) изпользуется Eclipse. Вернее сказать WebSphere Studio это специально заточенный Eclipse. И все это добро делает такая маленькая и неизвестная конторка с именем IBM.

_>Иначе слив засчитывается автоматически.

Получается что рано что-то считать.

Здравствуйте, DOOM, Вы писали:

DOO>Здравствуйте, gandjustas, Вы писали:

H>>>>>Конечно, .Net делает многое, чтоб оградить программиста от "сакральных" знаний. С этим никто не спорит.
G>>>>Это очень важный момент при разработке в большой команде.

DOO>>>Кто-то за это все равно платит — в данном случае, компенсируя отсутствие знаний у конечного кодера, архитектор должен залазить очень глубоко в проекте — т.е. все перевели на одного человека, это еще менее надежно.
G>>А разве схема "один мегаархитектор и куча быдлокодеров" где-то работает?

DOO>Ну вот. Ты сам понимаешь, что такое невозможно — так что придется кодеру вникать, никуда не денется.
Это не зависит от языка и платформы. В любом случае нужны толковые программисты кроме мегаархитектора.
Только в Delphi например, любой кодер может утечку памяти в люом месте вызвать, в отличие от .NET и Java

Здравствуйте, gandjustas, Вы писали:


G>Это не зависит от языка и платформы. В любом случае нужны толковые программисты кроме мегаархитектора.
Ну вот. Т.е. .Net, .Net'ом а руки все-таки должны расти из правильного места...

G>Только в Delphi например, любой кодер может утечку памяти в люом месте вызвать, в отличие от .NET и Java
Ну я думаю по незнанию и в .Net с джавой тоже можно изрядно напортачить (в крайнем случае насмотрелся я на бажные продукты циски, писанные на джаве).

Здравствуйте, hattab, Вы писали:

___>>Не спорю. Но тем не менее никакого отношения к "пердмету" разговора не имеющая. Или скажем по другому: юзеры/админы относятся к Дельфи/C#-ДотНет также как считать, что пользователи могут залить клавиатуру кофе недостатком клавиатуры.

H>Delphi не обязывает программиста иметь конфигурационные файлы, от которых будет зависеть работоспособность приложения. Вот и вся разница.

.NET никого ни к чему не обязывает. Окстись.