Юрий, ну про себя-то я точно знаю, что написал генерацию запросов сам )
Или вы имели в виду ситуацию, когда моим модулем пользуется другой программист, и не может разобраться в сгенерированном запросе? Ну, тут два варианта: 1. Это опытный программист, он разберется. 2. Это младший программист, он разобраться не может. Тогда ему придется обратиться ко мне или к другим старшим товарищам.
Я беру именно ту ситуацию, которую описал - генератор запросов создан в той команде, которая пишет программу.
Если рассматривать ситуацию, когда генератор запросов продается и используется какой-то другой командой - тут да, тут может потребоваться техподдержка от команды-разработчика. Скажем, последние годы я пользуюсь ORM DataObjects.Net фирмы Xtensive, и иногда приходится обращаться к ним за помощью. (Впрочем, со скоростью выполнения запросов вопросов не было.) Если бы у них не было техподдержки - возможно, мы бы использовали другую ORM, скажем, ту же Entity Framework.
У Паскаля, наверное, вообще политика такая - чтоб было проще, и чтоб не вводить новый синтаксис без необходимости.
А вот в C# скорее наоборот - чуть что, вводится новый синтаксический элемент - то лябды, то LINQ, то еще чего... В результате изучение C# намного сложнее, чем Паскаля, по моим ощущениям.
Так что вполне возможно, что действительно просто не хотят вводить новое без необходимости.
То есть все интерфейсы по-прежнему порождены от IUnknown? ОК. Но значит ли это, что любой интерфейс автоматически имеет реализацию, отслеживающую количество ссылок, и освобождающую объект, когда ссылок на него нет?
(Я помню, что такое было у COM-объектов, раньше, году так в 2000... Но с тех пор я сам перешел на C#, где объявление интерфейса означает только, что у класса есть такие функции, но они могут быть и абстрактными, т.е. без реализации вообще, и уж точно никогда нельзя гарантировать, что вот этот интерфейс будет иметь вот такую реализацию. Поэтому и спрашиваю у тех, кто может быть в курсе сегодняшнего состояния Паскаля в Дельфах.)
Я помню еще питерский клон Yaffil, потом слившийся с командой FireBird, если не ошибаюсь. Там они научились комбинировать индексы и очень быстро искать, скажем, при условиях по полям Name и INN и при индексах по каждому из этих полей, но без индекса по ним обоим. Поиск прям очень быстро стал работать.
Ну, там еще много хорошего было, уже и не вспомню точно, почти 20 лет прошло...
Что значит "не надо писать"? Вы хотели сказать, что они уже есть, и поэтому их не надо писать? Ну, так тогда и во всех других средах их так же "не надо писать".
Речь-то шла о том, чтоб при желании написать свой компонент, такой как тебе надо. Или, может быть, чуток доработать существующий. И вот тут и вылезает разница: в Delphi это сделать довольно легко. А в Visual Basic и Visual Fox Pro это не сделать. Нужно использовать другой язык, и на нем делать, и не так оно просто. На C#, кстати, с компонентами еще проще чем в Delphi. Может быть поэтому для него компонентов просто безумное количество.
Еще вопрос - а для чего и почему используете хранимые процедуры? Их же отлаживать и менять на порядок сложнее, чем алгоритм на Паскале? Или вам так критична скорость? Или просто вам нравится писать это на SQL?
Ну, строго говоря, блокируют друг друга не транзакции, а сессии, в которых делаются блокировки. Так что Сергей Дмитриевич прав, и я с ним не спорю. )
А если лезть в механизмы - то в сессиях производится обращение к критической секции, и взаимоблокировка случается когда два потока блокируют по критической секции и пытаются заблокировать вторую, блокированную другим потоком.
Ох и геморрой был разматывать эти блокировки в BDE в сервере приложений!
Я счел эту подробность неважной, хотя она хорошо укладывается в общую канву беспорядочных метаний.
А насчет Ембаркадеро - тут чуть другое. Сами остатки Борланда, действительно, уже не имели сил, чтоб что-то удержать. А Ембаркадеро - старая фирма, которая, по всей вероятности, не собиралась впадать ни в какие кризисы, и просто выкупила по дешевке команду Delphi, как старый лендровер у колхозника-раздолбая, чтоб отремонтировать в своем гараже и пользоваться.
Насколько я помню, печатал он все. Но с водяными знаками "Пробная версия" или что-то типа того. В платной версии эти отметки исчезали.
Т.е. можно было нормально отладить программу, даже обкатать на пользователях, и лишь потом купить FR.
Юрий, ну про себя-то я точно знаю, что написал генерацию запросов сам )
Или вы имели в виду ситуацию, когда моим модулем пользуется другой программист, и не может разобраться в сгенерированном запросе?
Ну, тут два варианта:
1. Это опытный программист, он разберется.
2. Это младший программист, он разобраться не может. Тогда ему придется обратиться ко мне или к другим старшим товарищам.
Я беру именно ту ситуацию, которую описал - генератор запросов создан в той команде, которая пишет программу.
Если рассматривать ситуацию, когда генератор запросов продается и используется какой-то другой командой - тут да, тут может потребоваться техподдержка от команды-разработчика.
Скажем, последние годы я пользуюсь ORM DataObjects.Net фирмы Xtensive, и иногда приходится обращаться к ним за помощью.
(Впрочем, со скоростью выполнения запросов вопросов не было.)
Если бы у них не было техподдержки - возможно, мы бы использовали другую ORM, скажем, ту же Entity Framework.
Что-то мне кажется, на ДВК сразу в .obj транслировалось. Потом в .sav, да.
А вот чтоб в ассемблер - не помню... 1988-90 год.
У Паскаля, наверное, вообще политика такая - чтоб было проще, и чтоб не вводить новый синтаксис без необходимости.
А вот в C# скорее наоборот - чуть что, вводится новый синтаксический элемент - то лябды, то LINQ, то еще чего... В результате изучение C# намного сложнее, чем Паскаля, по моим ощущениям.
Так что вполне возможно, что действительно просто не хотят вводить новое без необходимости.
Да, пожалуй что так...
С чего бы это вдруг? Если программист не может починить SQL-запрос, то что он тут делает? И как он его генератор написал?
Что-то вы себе напридумывали свое, нам такого не надо.
То есть все интерфейсы по-прежнему порождены от IUnknown?
ОК.
Но значит ли это, что любой интерфейс автоматически имеет реализацию, отслеживающую количество ссылок, и освобождающую объект, когда ссылок на него нет?
(Я помню, что такое было у COM-объектов, раньше, году так в 2000...
Но с тех пор я сам перешел на C#, где объявление интерфейса означает только, что у класса есть такие функции, но они могут быть и абстрактными, т.е. без реализации вообще, и уж точно никогда нельзя гарантировать, что вот этот интерфейс будет иметь вот такую реализацию.
Поэтому и спрашиваю у тех, кто может быть в курсе сегодняшнего состояния Паскаля в Дельфах.)
И был очень классно сделан!
И, кстати, в версии под .Net сделан так же хорошо.
И по сей день жив, как под Delphi, так и под C#.
Я помню еще питерский клон Yaffil, потом слившийся с командой FireBird, если не ошибаюсь. Там они научились комбинировать индексы и очень быстро искать, скажем, при условиях по полям Name и INN и при индексах по каждому из этих полей, но без индекса по ним обоим. Поиск прям очень быстро стал работать.
Ну, там еще много хорошего было, уже и не вспомню точно, почти 20 лет прошло...
Что значит "не надо писать"? Вы хотели сказать, что они уже есть, и поэтому их не надо писать?
Ну, так тогда и во всех других средах их так же "не надо писать".
Речь-то шла о том, чтоб при желании написать свой компонент, такой как тебе надо. Или, может быть, чуток доработать существующий.
И вот тут и вылезает разница: в Delphi это сделать довольно легко. А в Visual Basic и Visual Fox Pro это не сделать. Нужно использовать другой язык, и на нем делать, и не так оно просто.
На C#, кстати, с компонентами еще проще чем в Delphi. Может быть поэтому для него компонентов просто безумное количество.
Еще вопрос - а для чего и почему используете хранимые процедуры?
Их же отлаживать и менять на порядок сложнее, чем алгоритм на Паскале?
Или вам так критична скорость? Или просто вам нравится писать это на SQL?
А серверную часть в таком варианте можно под любую ОС собрать? Или?
Скажу вам, как старый пасквилянт старому сишнику )
Теоретически, можно было объявить тип массива с индексом от нуля до нужного вам значения. Что-то типа такого
Type
TIndex0_9 = 0..9;
TArray0_9Integer = Array[TIndex0_9] of Integer;
var MyArray: TArray0_9Integer;
"есть Модель (класс контрола), а есть его Представление (стиль)"
Это откуда вы такие термины взяли для данного случая?
Модель и Представление - это о данных, с которыми работает программа.
А класс контрола - это, извините, никак не модель. Это служебный класс, используемый в элементах представления.
Простите, но вы сильно путаетесь в терминологии. Либо исповедуете идеи какой-то экзотической школы.
У меня Delpi 7 под Windows 7 встал без проблем.
Как будет работать на Win 10 - попробую, скажу.
Ну, строго говоря, блокируют друг друга не транзакции, а сессии, в которых делаются блокировки. Так что Сергей Дмитриевич прав, и я с ним не спорю. )
А если лезть в механизмы - то в сессиях производится обращение к критической секции, и взаимоблокировка случается когда два потока блокируют по критической секции и пытаются заблокировать вторую, блокированную другим потоком.
Ох и геморрой был разматывать эти блокировки в BDE в сервере приложений!
Очень вероятно, что таки разработали бы. Про Java ведь Гейтс на самом деле говорил, что он всем хорош, кроме того, что разработан не нами.
Ну, Кан, возможно, и не дал бы.
Но Кан ушел. А Гейтс предложил три миллиона баксов. Ну, согласитесь, устоять трудно )
Ну, на SQL не так много пишут. С тех пор, как появились хорошие средства разработки программ с БД, бизнес-логику удобнее писать на других языках.
Я вот вообще даже SQL-запросы по большей части программно генерировал, а не писал руками.
Я счел эту подробность неважной, хотя она хорошо укладывается в общую канву беспорядочных метаний.
А насчет Ембаркадеро - тут чуть другое. Сами остатки Борланда, действительно, уже не имели сил, чтоб что-то удержать. А Ембаркадеро - старая фирма, которая, по всей вероятности, не собиралась впадать ни в какие кризисы, и просто выкупила по дешевке команду Delphi, как старый лендровер у колхозника-раздолбая, чтоб отремонтировать в своем гараже и пользоваться.