вторник, 4 июня 2013 г.

Насколько кстати Embarcadero "смотрит криво" на правку тех исходников, которые она поставляет?

Насколько кстати 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

Комментариев нет:

Отправить комментарий