Насколько кстати Embarcadero "смотрит криво" на правку тех исходников, которые она поставляет?
Надо сказать, что ДАЛЕКО НЕ ВСЕ собираются. И не только System.pas. Хотя и его мы когда-то умели собирать. С ключём -Y.
Но и без того - хватает.
Банальный пример - Variants, или ZLib.
И вот тоже пример - http://18delphi.blogspot.com/2013/06/hashlittle-overflowchecks-off.html
Или это "вообще запретная тема"?
И вообще - Embarcadero - восприимчива к дискуссиям - "как бы поправить исходники"? Например в Classes.pas, например для "примесей" в компонентах.
Например вот:
procedure RegisterClass(AClass: TPersistentClass);
begin
RegGroups.Lock;
try
while not RegGroups.Registered(AClass) do
begin
try
RegGroups.RegisterClass(AClass);
except {V}
on E : EFilerError do
if (Format(SDuplicateClass, [AClass.ClassName]) = E.Message) then
// do nothing
else
raise;
end;//try..except {/V}
if AClass = TPersistent then Break;
AClass := TPersistentClass(AClass.ClassParent);
end;
finally
RegGroups.Unlock;
end;
end;
Или Embarcadero имеет свою политику и не хочет даже ввязываться в дискуссии?
Например они говорят - "все ваши правки - это ваша головная боль". Или нет?
Вот скажем "примеси через include" это вообще комильфо? Или стоит задумываться об из замене? Если о замене, то я честно говоря - пока не знаю как. Да и вообще не уверен - возможно ли это.
Просто если Embarcadero "смотрит на это косо", то нам что-то надо с этим делать. У нас написан не один десяток миллионов строк кода....
А если "не криво", то хотелось бы рассказать о "своих чаяньях". Их по-сути - не много... Приведённый ВЫШЕ код - САМЫЙ критичный. Если мы не сможем компилировать Classes.pas, с подобными правками - мы не сможем компилировать свой код вообще. А значит - мы останемся "в рамках Delphi 7". Когда "код был ничей".
P.S. Ну есть конечно "другой путь" (которым мы и так идём, потому что мы думали, что Delphi - умер) - отказ от dfm и RAD и замена их на UML. И "в пределе" мы рассматривали Free-Pascal. Хотя там тоже - ЕСТЬ ПРОБЛЕМЫ, но там как минимум есть исходники компилятора.
Хотя хотелось бы НАОБОРОТ - "вернуться в рамки RAD и dfm". Но хотелось бы конечно в новом качестве.
Если бы "меня спросили" что делать с dfm - я бы ответил бы - "уходить от абсолютных координат". Относительные Layout'ы. Не более того. С процентами или constraint'ами. Ну и КОНЕЧНО - я бы сделал бы возможность КОММЕНТАРИЕВ в dfm.
Это "и мне" с UML - "на руку". В комментариях же можно - "мета-информацию" зашивать.
P.P.S. И конечно хотелось бы возможности "зашития" в dfm НАСТОЯЩЕЙ мета-информации. Например тех же АТРИБУТОВ. Ну и конечно IfDef. Ну и комментариев конечно же. Повторяюсь..
P.P.P.S. А ещё бы я конечно "скрестил" бы dfm, Visual Live Binding и UML, и (возможно) ER. Тогда - будет РЕАЛЬНЫЙ RAD.
P.P.P.P.S. Под возможностью "скрестить dfm с RAD и UML" я подразумеваю следующее - "рисуем" на dfm "контролы" ввода/вывода и "мапируем" их на "бизнес логику". ПОХОЖЕ на VLB! И может быть - это оно "где-то и есть". Тут надо додумать. Просто в моём представлении - "бизнес-объекты" - не просто "Observer", а скорее - "микросхемы", со входами и выходами. Тут надо додумывать. У меня-то есть своя "разрисовка" всей этой концепции, но она во-первых - не факт, что правильная, а во-вторых - "ДСП"... О! Оно - "проприетарно"...
Но! "Мои" бизнес-объекты, формы и "сборки форм" - гораздо продвинутей VLB. Мы даже пытались делать свои "редакторы свойств", визарды, шаблоны приложений и форм. И даже пользовались этим лет 5. Но ушли на UML - ибо - "изобразительных средств не хватило".
А ведь сколько! Споров было "бизнес-объект" или УЖЕ не "бизнес-объект", а ПРЕДСТАВЛЕНИЕ. А ГДЕ реализация ПРЕЦЕДЕНТА? А где данные? А где ПРЕДСТАВЛЕНИЕ? А как на уровни делить?
Publisher/Subscriber? Или Operation?
Кстати - "GoF" - я бы как-нибудь "втиснул бы" в рамки RAD. RAD без GoF (или чего-то подобного) - это - "школота". Простите уж за резкость... :-(
"Кидать на формы компоненты и определять ОБРАБОТЧИКИ", это мне РАЗОНРАВИЛОСЬ через ГОД общения с Delphi. Хотя это и КРУТО!
У меня и VCM родилось с "противовес" киданию компонентов на формы - http://18delphi.blogspot.com/2013/03/vcm.html
Надо сказать, что ДАЛЕКО НЕ ВСЕ собираются. И не только System.pas. Хотя и его мы когда-то умели собирать. С ключём -Y.
Но и без того - хватает.
Банальный пример - Variants, или ZLib.
И вот тоже пример - http://18delphi.blogspot.com/2013/06/hashlittle-overflowchecks-off.html
Или это "вообще запретная тема"?
И вообще - Embarcadero - восприимчива к дискуссиям - "как бы поправить исходники"? Например в Classes.pas, например для "примесей" в компонентах.
Например вот:
procedure RegisterClass(AClass: TPersistentClass);
begin
RegGroups.Lock;
try
while not RegGroups.Registered(AClass) do
begin
try
RegGroups.RegisterClass(AClass);
except {V}
on E : EFilerError do
if (Format(SDuplicateClass, [AClass.ClassName]) = E.Message) then
// do nothing
else
raise;
end;//try..except {/V}
if AClass = TPersistent then Break;
AClass := TPersistentClass(AClass.ClassParent);
end;
finally
RegGroups.Unlock;
end;
end;
Или Embarcadero имеет свою политику и не хочет даже ввязываться в дискуссии?
Например они говорят - "все ваши правки - это ваша головная боль". Или нет?
Вот скажем "примеси через include" это вообще комильфо? Или стоит задумываться об из замене? Если о замене, то я честно говоря - пока не знаю как. Да и вообще не уверен - возможно ли это.
Просто если Embarcadero "смотрит на это косо", то нам что-то надо с этим делать. У нас написан не один десяток миллионов строк кода....
А если "не криво", то хотелось бы рассказать о "своих чаяньях". Их по-сути - не много... Приведённый ВЫШЕ код - САМЫЙ критичный. Если мы не сможем компилировать Classes.pas, с подобными правками - мы не сможем компилировать свой код вообще. А значит - мы останемся "в рамках Delphi 7". Когда "код был ничей".
P.S. Ну есть конечно "другой путь" (которым мы и так идём, потому что мы думали, что Delphi - умер) - отказ от dfm и RAD и замена их на UML. И "в пределе" мы рассматривали Free-Pascal. Хотя там тоже - ЕСТЬ ПРОБЛЕМЫ, но там как минимум есть исходники компилятора.
Хотя хотелось бы НАОБОРОТ - "вернуться в рамки RAD и dfm". Но хотелось бы конечно в новом качестве.
Если бы "меня спросили" что делать с dfm - я бы ответил бы - "уходить от абсолютных координат". Относительные Layout'ы. Не более того. С процентами или constraint'ами. Ну и КОНЕЧНО - я бы сделал бы возможность КОММЕНТАРИЕВ в dfm.
Это "и мне" с UML - "на руку". В комментариях же можно - "мета-информацию" зашивать.
P.P.S. И конечно хотелось бы возможности "зашития" в dfm НАСТОЯЩЕЙ мета-информации. Например тех же АТРИБУТОВ. Ну и конечно IfDef. Ну и комментариев конечно же. Повторяюсь..
P.P.P.S. А ещё бы я конечно "скрестил" бы dfm, Visual Live Binding и UML, и (возможно) ER. Тогда - будет РЕАЛЬНЫЙ RAD.
P.P.P.P.S. Под возможностью "скрестить dfm с RAD и UML" я подразумеваю следующее - "рисуем" на dfm "контролы" ввода/вывода и "мапируем" их на "бизнес логику". ПОХОЖЕ на VLB! И может быть - это оно "где-то и есть". Тут надо додумать. Просто в моём представлении - "бизнес-объекты" - не просто "Observer", а скорее - "микросхемы", со входами и выходами. Тут надо додумывать. У меня-то есть своя "разрисовка" всей этой концепции, но она во-первых - не факт, что правильная, а во-вторых - "ДСП"... О! Оно - "проприетарно"...
Но! "Мои" бизнес-объекты, формы и "сборки форм" - гораздо продвинутей VLB. Мы даже пытались делать свои "редакторы свойств", визарды, шаблоны приложений и форм. И даже пользовались этим лет 5. Но ушли на UML - ибо - "изобразительных средств не хватило".
А ведь сколько! Споров было "бизнес-объект" или УЖЕ не "бизнес-объект", а ПРЕДСТАВЛЕНИЕ. А ГДЕ реализация ПРЕЦЕДЕНТА? А где данные? А где ПРЕДСТАВЛЕНИЕ? А как на уровни делить?
Publisher/Subscriber? Или Operation?
Кстати - "GoF" - я бы как-нибудь "втиснул бы" в рамки RAD. RAD без GoF (или чего-то подобного) - это - "школота". Простите уж за резкость... :-(
"Кидать на формы компоненты и определять ОБРАБОТЧИКИ", это мне РАЗОНРАВИЛОСЬ через ГОД общения с Delphi. Хотя это и КРУТО!
У меня и VCM родилось с "противовес" киданию компонентов на формы - http://18delphi.blogspot.com/2013/03/vcm.html
Комментариев нет:
Отправить комментарий