Delphi 2005

← →
Суслик © (2004-12-06 14:46) [40]

> Access violation in borlndmm.dll

в этой библиотеке (если запомнил верно) я видел несколько багов, и все AV :(((

← →
DiamondShark © (2004-12-06 14:47) [41]

Гы :)
Таки, узнал.
Первые 256 байт.

Кто бы мог подумать...

← →
vuk © (2004-12-06 14:50) [42]

to DiamondShark © (06.12.04 14:43) [39]:
До 4-й позиции от начала файла наличие "я" в тексте роли не играет.

← →
iZEN © (2004-12-06 14:51) [43]

by © (06.12.04 11:51) [3]
портит все маленькая буква "я" в тексте комментариев в начале модуля. Если в новой среде написать такой комментарий в начале модуля, то он редактиреутся нормально. Но, если его закрыть, то вновь откроется он в двоичном виде.
Вот так лажа. Не ожидал я такого от Borland.
Русские буквы в названиях каталогов проекта Проекты VCL.NET и WinForms не запускаются из-под среды, если в полном имени каталога проекта есть русские буквы. Среда сообщает "Unable to create process".
Дык это, когда .Net копировали с Java, скопировали и эту фичу. ;)))
К сожалению, ссылки в окне "Help Insight" не будут работать, если у вас в названии каталогов используются русские буквы.Вот такая вот селява...

← →
by © (2004-12-06 14:54) [44]

offtop
Идет целенаправленная политика уничтожения буквы "я" )))
Не дадим Борланду покусится на xfcnm алфавита, а то скоро и до других букв у них руки дойдут ))
offtop

← →
by © (2004-12-06 14:54) [45]

xfcnm = часть

← →
Суслик © (2004-12-06 14:56) [46]

вообще говоря, "я", "ю" и прочие буквы все фигня - буду на англицком писать, а вот то, что у меня только 20% проекта сбилдилось действительно пугает.

Пытался ли кто билдить проекты более 200 тыс строк?

← →
iZEN © (2004-12-06 15:01) [47]

/**Суслик © (06.12.04 14:46) [40]
> Access violation in borlndmm.dll
в этой библиотеке (если запомнил верно) я видел несколько багов, и все AV :(((
*/
Это пока семачки. Всё ещё впереди.

В .Net нет объявленных исключений, принуждающих к обработке как в Java: void someMethod(...) throws SomeException {...} AV или что-то похожее рано или поздно вылезит неизбежно.

← →
vuk © (2004-12-06 15:01) [48]

<offtopic>
to iZEN © (06.12.04 14:51) [43]:
>Дык это, когда .Net копировали с Java, скопировали
>и эту фичу. ;)))
А в каких местах его скопировали?
</offtopic>

← →
DiamondShark © (2004-12-06 15:03) [49]

> vuk © (06.12.04 14:50) [42]
> to DiamondShark © (06.12.04 14:43) [39]:
> До 4-й позиции от начала файла наличие "я" в тексте роли
> не играет.

А в 5-й позиции влияет.
Фича.

Правда, если текст сохранить в UTF-8, то уже никакие "я" не страшны.

← →
Игорь Шевченко © (2004-12-06 15:09) [50]

DiamondShark © (06.12.04 15:03) [49]

А в старых версиях его потом возможно загрузить ?

С уважением,

← →
DiamondShark © (2004-12-06 15:11) [51]

> В .Net нет объявленных исключений, принуждающих к обработке
> как в Java: void someMethod(...) throws SomeException {...}

Во-первых, при чём тут НЕТ?
Во-вторых, нафиг эта дурь нужна?

← →
vuk © (2004-12-06 15:11) [52]

А я люблю исходники из FAR-а смотреть...

← →
DiamondShark © (2004-12-06 15:16) [53]

> Игорь Шевченко © (06.12.04 15:09) [50]

Загрузить можно.
Скомпилировать нельзя. ;-)

← →
iZEN © (2004-12-06 15:24) [54]

To vuk © (06.12.04 15:01) [48]
В имени пакета java не должно быть символов не английского алфавита. Пакет в java является частью пути к файлу класса.
Кстати, название типа Java не может быть неанглийским, хотя в именах идентификаторов и методов допускается использование любых unicode-символов (В 1998г. в JBuilder 1&2 я писал программы, используя русские идентификаторы и имена методов и всё прекрасно работало, вот).

to DiamondShark © (06.12.04 15:11) [51].
А как же совместимость?! .Net - это теперь база для Delphi.
Не будет вам никаких исключений, обязательных к обработке:
http://www.optim.ru/cs/2001/1/clr/c-sh.asp
Вас никто не заставляет обрабатывать хоть какие-то исключения. Как сказал один из сотрудников Microsoft, в том, что разработчики вынуждены обрабатывать исключения, больше вреда, чем пользы. Это приводит к большому количеству catch (Exception e)-обработчиков исключений, не делающих ничего полезного.

Есть мнение, что это неудачное решение, поскольку оператор throws делает очевидным, какие исключения возбуждаются методом и являются частью контракта метода. Иначе вы вынуждены читать исходный код вызываемого метода, чтобы узнать, какие исключения могут быть возбуждены. Но нам кажется, что при грамотной реализации такое решение может упростить программирование. Время покажет.

← →
Суслик © (2004-12-06 15:32) [55]

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

Граждане, ну неужели ни у кого нет проекта более 200 тыс строк? А?

← →
Суслик © (2004-12-06 15:38) [56]

С ECO разбарался кто-то?
Как впечатления?

← →
Sergey_Masloff (2004-12-06 15:41) [57]

Суслик © (06.12.04 15:32) [55]
>Граждане, ну неужели ни у кого нет проекта более 200 тыс строк? >А?
Проекты есть. Нет времени на страдание ерундой ;-)
Нет, серьезно, в упор не понимаю необходимости установки D2005 и попыток на нее что-то переносить. Просто из спортивного интереса?

← →
by © (2004-12-06 15:42) [58]

Суслик © (06.12.04 15:38) [56]
Тут недавно в ветке об UML ECO подверглись критике, хотя Борланд настойчиво пытается впихнуть все это разработчику. Задумка интересная, типа чтобы голова не болела как объекты сохранять в БД, persistent layer. Но вот как оно будет работать, особенно на больших объемах. Хотя где-то резонно заметили, что если у вас в приложении двигаются большие объемы данны, то стоит задуматься об архитектуре.

← →
Суслик © (2004-12-06 15:43) [59]

> [57] Sergey_Masloff (06.12.04 15:41)

Ты слышал, что С. Орлик говорил недели две назад (можешь поиском поискать)?

"Life time delphi 6 кончился."

← →
by © (2004-12-06 15:44) [60]

Sergey_Masloff (06.12.04 15:41) [57]
Ну спортивный интерес и желание нового тоже присутствует, но больше конечно новые возможности редактора прельщают, плюс одна среда для win32 и .Net. Но пока рановато переходить, так как еще не все компоненты есть для 2005.

← →
Sergey_Masloff (2004-12-06 15:45) [61]

Зря конечно я в этой ветке. Но все же не удержусь еще камень в борландовский огород:

>С ECO разбарался кто-то?
Ага. "Клиент-серверная" технология в терминах Борланд. Под "К-С" понимается использование сервера как набора таблиц, то есть технология фокспро и парадоксов в своем абсолютном выражении. На фига хранимые процедуры и триггеры, можно ж все написать дельфовым кодом. Эффективность? А зачем она на современных крутых тачках!!!! Ах, не зватает даже крутых тачек? Так это неправильно технологию выбрали! Для пацанских приложений только трехзвенка!
Вобщем, ECO это точно тупиковая ветка. ИМХО не пишу специально - потому что в полной мертворожденности технологии уверен на 99.9%

← →
wisekaa © (2004-12-06 15:45) [62]

> [46] Суслик © (06.12.04 14:56)

Есть, но скомпилить нет возможности из-за отсутствия портированных компонент.

← →
Суслик © (2004-12-06 15:46) [63]

> интересная, типа чтобы голова не болела как объекты сохранять
> в БД, persistent layer. Но вот как оно будет работать, особенно
> на больших объемах.

На больших и реляционки работают так себе :)))
И вообще, что считать большими объемами?
Хранение данных для поисковых серверов интернера? Так это и реляционка с трудом прокачает.
Хранение 30 тыс бизнес объектов? Так для этого и скорости особе не надо.
В общем все это субъективно. Скорее успех eco будет зависеть от всеобщей поддержки и со стороны пользователей и со стороны конкурентов.

← →
by © (2004-12-06 15:49) [64]

Sergey_Masloff (06.12.04 15:45) [61]
Получается что любой persistent layer или OR mapping основанные на сопоставлении полей таблиц и полей объектов обресчены на неудачу и забвение? Или только конкретная реализация ввиде Bold или ECO?

← →
by © (2004-12-06 15:52) [65]

Суслик © (06.12.04 15:46) [63]
Большие для меня - это когда мне нужно для 3 000 000 записей за месяц сделать расчет по разным тарифным планам. И если я эту кучу буду вкачивать в объекты, то никаких ресурсов не хватит. Хотя если по одному, вкачали, обработали, записали, очистили, то будет жить. Вот только позволит ли так поступить тот же ECO.

← →
Sergey_Masloff (2004-12-06 15:52) [66]

Суслик © (06.12.04 15:43) [59]
>Ты слышал, что С. Орлик говорил недели две назад (можешь >поиском поискать)?
>"Life time delphi 6 кончился."
Слышал даже своими ушами а не читал. И что с того? Наш основной проект на Delphi 5 (а начинался на Delphi 2), прекрасно продолжает дописываться, ничего нужного начиная с 5 Delphi не добавилось - так чего нервничать. Да лайфтайм закончился - что с того? Что новую купить нельзя? Отлично как только мне понадобится новая лицензия я куплю последнюю версию. Но не до тех пор.
У нас куплены и 6, и 7 и 8-я Delphi, если с 6 и 7 я еще внимательно разбирался в нововведениях и для интереса портировал проект (не боевую версию) то теперь с меня хватит.
Да и 2 среды в одной как я уже спорил с кем-то это не фича а лишние проблемы.
Я так думаю ;-)

← →
DiamondShark © (2004-12-06 15:53) [67]

> iZEN © (06.12.04 15:24) [54]

> А как же совместимость?! .Net - это теперь база для Delphi.

Чего с чем совместимость?
Дельфи с НЕТ нормально совместились.

> Как сказал один из сотрудников Microsoft, в том, что разработчики
> вынуждены обрабатывать исключения, больше вреда, чем пользы.

Совершенно верно сказал.

> Иначе вы вынуждены читать исходный код вызываемого метода,
> чтобы узнать, какие исключения могут быть возбуждены.

А меня совершенно не интересует, какие исключения могут быть возбуждены.
Или интересуют не все.
Или интересуют только некоторые классы.

Они хотят меня заставить обрабатывать все исключения? Ага, щаз.
Если я не хочу это делать, то никто не запретит мне повторить список исключений в заголовке своего метода, и так же преспокойно передать их выше по вызову.

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

← →
Sergey_Masloff (2004-12-06 15:56) [68]

by © (06.12.04 15:49) [64]
>Получается что любой persistent layer или OR mapping
Ну это слишком сильное утверждение ;-)
Но их есть полно, много лет эта тема муссируется а "выхлопа" - ноль. Все это красиво работает в маленьких тестовых примерах (где оно не нужно) и ИМХО совсем не работает когда приходится копнуть подальше.
Я сам буквально "болел" ORM но что-то как показала практика особых преимуществ подход не имеет. Да, кое-что удобнее, кое-что - совсем неудобно вобщем не серебряная пуля это точно, а может и похуже ;-)

> На фига хранимые процедуры и триггеры, можно ж все написать
> дельфовым кодом.

Для БД-серверов красивых RAD-IDE нету, SQL ручками пейсать приходится.
А це нынче не модно.
;-)

← →
Sergey_Masloff (2004-12-06 15:59) [70]

DiamondShark © (06.12.04 15:53) [67]
>Т.о., обязательное описание исключений -- фича совершенно >лишняя: компилятор и программирование усложняет, а никаких >реальных задач не решает.
"Да он мог бы прямо на митингах деньги зарабатывать!" (с) Шариков. Нет, кроме шутки, по-хорошему завидую твоему умению сжато и точно формулировать. По сути согласен но мне так кратно не сказать ;-)

С уважением

> by © (06.12.04 15:52) [65]

3000000 записей для хорошего SQL-сервера -- не объём.
А для любой ОО-нашлёпки -- смерть.

Долой третий layer и пятое колесо!

Sergey_Masloff (06.12.04 15:56) [68]
Я сейчас начитавшишь книжек усиленно копал в этом направлении. Но (ИМХО) уже вижу что для языков/IDE (Delphi и .Net) в которых ярко выражена концепция DataSet и есть куча методов работы с ним, в том числе и DBAware компоненты, лучшим методом будет будет модель таблицы с шлюзами к реальным таблицам БД. И нечего на все это натягивать объекты. Главное развязать визуальное отображение (форму) и логику.
Сорри за офтопик.

> [65] by © (06.12.04 15:52)

Какие eco, когда речь идет про 3 млн?
Думаю тут однозначно реляционка или еще что.

> [68] Sergey_Masloff (06.12.04 15:56)

> > На фига хранимые процедуры и триггеры, можно ж все написать дельфовым кодом.

Позволь заметить, что все зависит от задачи. В том числе и от предполагаемых объемов информации. У нас многое написано именно дельфовым кодом. При этом имеется в активе приемы ООП. Полиформизм, в частности, в некоторых задачах имеет свой смысл. Не вижу в этом ничего плохого. Я бы посмотрел, как на sql сервере написали скрипт поддерживающих логику нашего счета-фактуры. Наверное можно, но вот обозримость и поддерживаемость точно ниже будет.

Да, мы страдаем от потерь скорости. Этого не отнять. Но пока об архитектурном решении ни разу не пожалели.

> [71] DiamondShark © (06.12.04 16:01)
>
> Долой третий layer и пятое колесо!

Да зраствуют собственные сервера!

> [71] DiamondShark © (06.12.04 16:01)
> 3000000 записей для хорошего SQL-сервера -- не объём.
> А для любой ОО-нашлёпки -- смерть.

Хотелось бы с этим не согласится.

Я полагаю, что все зависит от подхода и задач. С точки зрения построения отчетов я полагаю, что sql лучше всего. С точки зрения insert\update\delete, то с твоим утверждением не могу до конца согласится. Важно понимать интенсивность таких операций.

Мы комбинируем два подхода. Пока проблем нет.

← →
Sergey_Masloff (2004-12-06 16:19) [75]

Суслик © (06.12.04 16:08) [73]
>Позволь заметить, что все зависит от задачи. В том числе и от >предполагаемых объемов информации.
Согласен

>При этом имеется в активе приемы ООП. Полиформизм, в частности, >в некоторых задачах имеет свой смысл.
И PL/SOL и T/SQL наверняка позволяют сделать то же самое. Пусть немного по-другому.

>Я бы посмотрел, как на sql сервере написали скрипт >поддерживающих логику нашего счета-фактуры
Да написали бы. Была б логика а реализовать ее хоть на счетах можно. У нас серверного кода раза в 2 больше дельфийского (а дельфийского сравнимо с тем что у тебя, не 2 млн. конечно но в рапйоне 1 точно). И ничего - и читается нормально, и поддерживается ИМХО проще дельфийского кода, и между платформами переносится совершенно прозрачно, вобщем плюсы перечислять пальцев не хватит. ;-)

С уважением

> [75] Sergey_Masloff (06.12.04 16:19)

> вобщем плюсы перечислять пальцев не хватит. ;-)

Самый главный плюс, это ты, скорее всего, sql:

1) либо знаешь лучше всего
2) либо начал изучать раньше и больше любишь
3) либо пришел в середине проекта, когда архитектура была ясна.

Может еще что-то...

С уважением.

Суслик © (06.12.04 16:17) [74]
Просто получается что прийдется писать свой ORM, под свои задачи. Готовые без ограничений использовать трудно.

> Готовые без ограничений использовать трудно.

я уверен, что невозможно :((

Потому и пользуюсь своим.

Суслик © (06.12.04 16:27) [78]
А свой ORM это много человеко-часов ((
И не факт что будет как надо. Фаулер рекомендует покупать )))

Delphi 2005 Найти похожие ветки